The title "Lisp from nothing"

doesn't seem to fit with:

"INTENDED AUDIENCE This is not an introduction to LISP."

on page 10.

"What else are lists, but alternatives?"

(credit to https://aphyr.com/posts/340-reversing-the-technical-intervie..., I always get a kick out of that and the follow up https://aphyr.com/posts/341-hexing-the-technical-interview).

As somebody who read a couple of the author's books, and also somebody who spent almost a decade studying compilers, I am genuinely curious about the author himself.

These works are something I both understand and would never achieve myself. These are cultural artifacts, like deeply personal poetry, made purely for the process of it. Not practically useful, not state of the art, not research level, but... a personal journey?

If the author is reading this... can you share your vision? Motivation?

Thank you so much for reading my books and describing my work in such beautiful words! You basically answered your own question! My motivation is just the creation of something I find beautiful. The vision, to pass knowledge to those who seek it in the simplest possible way, where "simple" does not necessarily mean in the tersest form, but in a form that invites being digested.

I do not usually talk much about "myself". I tried, but with no-one asking, I find it difficult to say anything.

“I have nothing to say and I am saying it”

Cage.

Thanks for An Introduction to Mental Development, I've throughly enjoyed it!

I second this, would be great if someone did a long form video interview with the author.

The book looks awesome. However, I find some irony in the presence of a “no AI” badge on the back cover considering Lisp was AI research.

Looking at file church.scm from the provided zip file [1], I see the following functions used to construct lists:

    (define kons
      (lambda (x) (lambda (y) ((pair false) ((pair false) ((pair x) y))))))
    
    (define kar   (lambda (x) (first (second (second x)))))
    (define kdr   (lambda (x) (second (second (second x)))))
    
    (define nil   ((pair true) ((pair true) false)))
    (define null  first)
    
    (define atom  (lambda (x) (first (second x))))

That's 2 extra booleans per list element. While the one for recognizing atoms is probably necessary, the other one for recognizing nil is not:

    (define kons
      (lambda (x) (lambda (y) ((pair false) ((pair x) y)))))
    
    (define kar   (lambda (x) (first (second x))))
    (define kdr   (lambda (x) (second (second x))))
    
    (define nil ((pair true) false))
    (define null (lambda (x) (((second x) (lambda (a) (lambda (d) (lambda (z) false)))) true)))
    
    (define atom  (lambda (x) (first x)))

The use of null+car+cdr can usually be avoided by using a matching construct instead like

    (((second list) (lambda (a) (lambda (d) (lambda (z) deal_with_car_a_and_cdr_d ) deal_with_nil)

[1] https://t3x.org/lfn/church.zip

But then (ATOM NIL) is neither TRUE nor FALSE.

I forgot to add the atom boolean to the nil representation. I made some changes that hopefully fix that.

Indeed, thanks!

Second edition, with a new chapter on lambda calculus.

Thanks. I recently had to reinvent LISP to script my CRDT database. That was not much work, because I already had the notation (I use RDX, a JSON superset with CRDT types). Still, I stumbled at the idiosyncratic LISP bracketing. Luckily, RDX allows for different tuple notations. So, I styled it to look less alien to a curly-braced developer. Like this https://github.com/gritzko/go-rdx/blob/main/test/13-getput.j...

For example, print change-dir make-dir; is equivalent to (print (change-dir (make-dir) ) ) in the old money. I wonder if I am reinventing too much here.

Did LISPers try to get rid of the brackets in the past?

There have been many attempts to get rid of sexprs in favor of a “better” syntax. Even John McCarthy, the inventor (discoverer?) of Lisp had plans for an “M-expression” syntax to replace “S-expressions.” It never happened. The secret is that Lispers actually view sexprs as an advantage, not something to be worked around. Once you discover symbolic editing and code manipulation based on sexprs, you’ll never go back to weak line editing. That said, some Lisp dialects (e.g. Clojure and Racket) have embraced other symbols like square and curly brackets to keep the code more terse overall and optically break up longer runs of parentheses.

Probably the best example of a “Lisp without parentheses” is Dylan. Originally, Dylan was developed as a more traditional Lisp with sexprs, but they came up with a non-sexr “surface syntax” before launching it to avoid scaring the public.

I actually really appreciate Racket's judicious use of square brackets in let expressions. It just makes visual parsing that much easier.

Yes, and it has never stuck. Even the great John McCarthy, the very creator of Lisp, couldn't manage it: <https://en.wikipedia.org/wiki/M-expression>.

I sometimes wonder if the issue is really the parentheses or the ease of nesting. In LISP it’s natural to write (f (g (h x))). Whereas most people are used to. a = h(x); b = g(a); c = f(b);

In C/C++ most functions return error codes, forcing the latter form.

And then there are functional languages allowing: x -> h -> g -> f but I think the implicit parameter passing doesn’t sit well with a lot of programmers either.

Interesting comment. I found the lisp/sexpr form instantly understandable. While the others weren't hard to grasp it took a moment to consciously parse them before their meaning was as clear. Perhaps the functional arrow notation is least appreciated because it's seems more abstract or maybe the arrows are just confusing.

More likely than not it's a matter of what a person gets used to. I've enjoyed working in Lisp/Scheme and C, but not so much in primarily functional languages. No doubt programmers have varied histories that explain their preferences.

As you imply, in C one could write nested functions as f (g (h (x))) if examining return values is unnecessary. OTOH in Lisp return values are also often needed, prompting use of (let ...) forms, etc., which can make function nesting unclear. In reality programming languages are all guilty of potential obscurity. We just develop a taste for what flavor of obscurity we prefer to work with.

Many times. A google for "sweet expressions lisp" will give you a bunch of implementations and opinions.

Aha, thanks https://dwheeler.com/readable/

I laughed at this one: I have more faith that you could convince the world to use esperanto than [to use] prefix notation. - Paul Prescod

Thanks.

If you don't get an answer here, try to contact the author directly through his website, he is pretty responsive.

tug2024 wrote: > Doesn’t lisp extend lambda calculus (abstraction . application)? As a consequence, lisp (abstraction . application . environment)!

Another valid question downvoted into oblivion.

The environment in (lexically scoped) LISP is an implementation detail. Lambda calculus does not need an environment, because variables are substituted on a sheet of paper. So lambda calculus equals lexically scoped LAMBDA in LISP.

Sure, you could view LISP as LC plus some extra functions (that are not easily implemented in LC).

"... and the chicks for free "?

Haha, yes! You are the first one to notice or, at least, to respond.