Hacker Next
Lisp from Nothing, Second Editiont3x.org
99 points by nils-m-holm 2 days ago | 18 comments
vkazanov 44 minutes ago [-]
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?

AlexeyBrin 30 minutes ago [-]
I second this, would be great if someone did a long form video interview with the author.
tromp 2 hours ago [-]
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
nils-m-holm 1 hours ago [-]
But then (ATOM NIL) is neither TRUE nor FALSE.
tromp 21 minutes ago [-]
I forgot to add the atom boolean to the nil representation. I made some changes that hopefully fix that.
1 hours ago [-]
nils-m-holm 2 days ago [-]
Second edition, with a new chapter on lambda calculus.
gritzko 2 hours ago [-]
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?

drob518 2 hours ago [-]
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.

tmtvl 1 hours ago [-]
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>.
jbritton 22 minutes ago [-]
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.

fermigier 21 minutes ago [-]
https://en.wikipedia.org/wiki/Apple_Dylan
bryanlarsen 2 hours ago [-]
Many times. A google for "sweet expressions lisp" will give you a bunch of implementations and opinions.
gritzko 2 hours ago [-]
Aha, thanks https://dwheeler.com/readable/
lanstin 17 minutes ago [-]
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.

AlexeyBrin 2 hours ago [-]
If you don't get an answer here, try to contact the author directly through his website, he is pretty responsive.
nils-m-holm 1 hours ago [-]
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).

fermigier 23 minutes ago [-]
"... and the chicks for free "?
nils-m-holm 19 minutes ago [-]
Haha, yes! You are the first one to notice or, at least, to respond.
tug2024 2 hours ago [-]
[dead]