Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

These years in Common Lisp: 2023-2024 in review

lisp-journey.gitlab.io

Post reply on HN
Print view View original

41–50 of 54 posts

Re: These years in Common Lisp: 2023-2024 in review

#41

Post by tmtvl »

cenamus wrote: post #32
fovc wrote: post #28

Earlier quoted context omitted.

Having the data structures is nice and all, but using them is kind of painful. They are certainly second class. Having to use accessor functions or destructuring macros instead of just a period or -> is often annoying too. The lack of syntax has cons as well as pros.

I mean you can write a macro that let's you write (object -> slot) and transforms it to (slot object) "->" should be unused

Writing a reader macro that allows for something like...

  [some-numbers 0]
...to get the first (many programming languages make this mistake, using 0 to refer to the first element of a collection, so we can forgive CL for this) element. But I'm curious how you can write...

  (object -> slot)
...without getting an error about OBJECT not being a valid function or macro.

Re: These years in Common Lisp: 2023-2024 in review

#42

Post by fovc »

tmtvl wrote: post #41
cenamus wrote: post #32

Earlier quoted context omitted.

I mean you can write a macro that let's you write (object -> slot) and transforms it to (slot object) "->" should be unused

Writing a reader macro that allows for something like... [some-numbers 0] ...to get the first (many programming languages make this mistake, using 0 to refer to the first element of a collection, so we can forgive CL for this) element. But I'm curious how you can write... (object -> slot) ...without getting an error about OBJECT not being a valid function or macro.

And also make sure that slot is a symbol in the correct package. Or do like Elisp and do without packages but then have a 16 character prefix

Re: These years in Common Lisp: 2023-2024 in review

#43

Post by pjmlp »

veqq wrote: post #37
pjmlp wrote: post #36

Earlier quoted context omitted.

What FP style? Haskell style, I guess. When I learnt Lisp, Lisp and Scheme were FP, Miranda was still around, and Caml Light had just started being known outside INRIA. I really dislike revisionism regarding what it means to be FP.

The issue's that Schemes (and Clojure) are way more functional than Common Lisp and e.g. `funcall` feels like a kludge compared to lisp-1. If you read the old CL codebases or modern code, destructive and imperative use are common, so it doesn't feel terribly revisionist (just compared to pascal, c, bliss etc.).

So that rules out most ML derived language as well, pity Standard M, OCaml, F#, Scala are no FP as well. /s

Re: These years in Common Lisp: 2023-2024 in review

#44

Post by ludston »

andsoitis wrote: post #39
veqq wrote: post #37

Earlier quoted context omitted.

The issue's that Schemes (and Clojure) are way more functional than Common Lisp and e.g. `funcall` feels like a kludge compared to lisp-1. If you read the old CL codebases or modern code, destructive and imperative use are common, so it doesn't feel terribly revisionist (just compared to pascal, c, bliss etc.).

Wikipedia page for “functional programming”: ”The first high-level functional programming language, Lisp, was developed in the late 1950s…” https://en.wikipedia.org/wiki/Functional_programming

Common Lisp has Lisp in the name, but it is not the same thing. We're talking about languages developed 30 years apart here.

In the 80s, things like immutability just weren't pragmatic due to memory constraints, and CL was designed with pragmatism in mind. Scheme could be argued as FP. Clojure certainly is. CL is not.

Re: These years in Common Lisp: 2023-2024 in review

#46

Post by nextos »

trenchgun wrote: post #31
nextos wrote: post #19

Earlier quoted context omitted.

CLOS is great, but CL also supports pure typed FP with https://coalton-lang.github.io Coalton progress is discussed briefly in the OP: https://lisp-journey.gitlab.io/blog/these-years-in-common-li...

Coalton is its own language, just implemented and embedded in CL.

Sure, but Coalton has decent interop with CL.

Eventually, I expect this to be a relationship similar to Java and Scala or Clojure.

Re: These years in Common Lisp: 2023-2024 in review

#47

Post by darthrupert »

tmtvl wrote: post #40
Y_Y wrote: post #18

Earlier quoted context omitted.

Ya, when are we going to hear about "Clarc"? Where's the source?

I read that the source won't be made available because it contains some anti-spam (anti-abuse?) measures that would be easily circumvented if the source were open. Security through obscurity is famously no security at all, but I can see how it can reduce the noise that dang has to deal with a bit.

Anti-spam isn't security in that sense. Perfection is not required when dealing with irritation.

Re: These years in Common Lisp: 2023-2024 in review

#48

Post by Jach »

tmtvl wrote: post #41
cenamus wrote: post #32

Earlier quoted context omitted.

I mean you can write a macro that let's you write (object -> slot) and transforms it to (slot object) "->" should be unused

Writing a reader macro that allows for something like... [some-numbers 0] ...to get the first (many programming languages make this mistake, using 0 to refer to the first element of a collection, so we can forgive CL for this) element. But I'm curious how you can write... (object -> slot) ...without getting an error about OBJECT not being a valid function or macro.

A late reply but it's worth addressing one way of doing this. First, your concern about object not being a valid function or macro isn't relevant at read time. Second, note that Lisp already has similar syntax: '(1 . 2) is essentially (cons 1 2). Implementing this type of syntax is not a privilege of the implementation alone. You're allowed to redefine your own reader for left paren. In SBCL:

    CL-USER> (get-macro-character #\()
    SB-IMPL::READ-LIST
You can write `(set-macro-character #\( 'sb-impl::read-list)` and everything continues to work just fine. You can also jump-to-source and modify it if you want -- though it's cleaner to just copy it out to your own project, that's what I did for a quick hack/proof of concept. Essentially I added before the existing (when...) which handles the special dot syntax:

      (when (and (eq firstchar #\-)
                 (eq (peek-char t stream t nil t) #\>))
        (read-char stream t) ; actually read the nextchar > to discard it
        (let ((next-obj (read stream)))
          (sb-impl::flush-whitespace stream rt)
          (return `(slot-value ,@listtail ',next-obj))))
I won't claim this is good or proper, but it shows that it's quite feasible. We've turned (foo -> bar) into (slot-value foo 'bar).

    CL-USER> (defclass vec2 ()
      ((x :initarg :x)
       (y :initarg :y)))
    #
    CL-USER> (defparameter vec (make-instance 'vec2 :x 3 :y 4))
    VEC
    CL-USER> (vec -> y)
    4
    CL-USER> (read-from-string "(print (vec -> x))")
    (PRINT (SLOT-VALUE VEC 'X))
    18
Personally I wouldn't use this even if it was more properly/carefully implemented. (There's really no reason to replace the default left-paren reader, and no reason we have to have a space surrounding the "->". One thing I like about the infix reader macro package https://github.com/quil-lang/cmu-infix is that it doesn't care about spaces, I can write #I(1+1 + 4) and get 6.) I'm quite happy putting my class in its own package, and thus getting the primary tab-completion behavior I care about. e.g. "(ma:" could complete to "(math:" and then "(math:v" could complete to a list of options like "vector-x" "vector-y" or so on. I also like the somewhat unusual approach of naming my accessors with a dot prefix, e.g. (.x vec) and (.y vec), or even (math:.x vec) if I haven't imported the symbol.

Re: These years in Common Lisp: 2023-2024 in review

#49

Post by kazinator »

tmtvl wrote: post #41
cenamus wrote: post #32

Earlier quoted context omitted.

I mean you can write a macro that let's you write (object -> slot) and transforms it to (slot object) "->" should be unused

Writing a reader macro that allows for something like... [some-numbers 0] ...to get the first (many programming languages make this mistake, using 0 to refer to the first element of a collection, so we can forgive CL for this) element. But I'm curious how you can write... (object -> slot) ...without getting an error about OBJECT not being a valid function or macro.

> so we can forgive CL for this

The 1962 dated Lisp 1.5 Programmer's Manual already describes a 0 based array feature. Lisp was clearly one of the historic instigators of zero based array, rather than just playing along.

Re: These years in Common Lisp: 2023-2024 in review

#50

Post by tmtvl »

Jach wrote: post #48
tmtvl wrote: post #41

Earlier quoted context omitted.

Writing a reader macro that allows for something like... [some-numbers 0] ...to get the first (many programming languages make this mistake, using 0 to refer to the first element of a collection, so we can forgive CL for this) element. But I'm curious how you can write... (object -> slot) ...without getting an error about OBJECT not being a valid function or macro.

A late reply but it's worth addressing one way of doing this. First, your concern about object not being a valid function or macro isn't relevant at read time. Second, note that Lisp already has similar syntax: '(1 . 2) is essentially (cons 1 2). Implementing this type of syntax is not a privilege of the implementation alone. You're allowed to redefine your own reader for left paren. In SBCL: CL-USER> (get-macro-char…

Good things are worth waiting for. I never considered making a reader macro for a regular opening bracket, that's equal parts genius and insanity.
Post reply on HN