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?
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.
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).
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?
Looking at file church.scm from the provided zip file [1], I see the following functions used to construct lists:
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: The use of null+car+cdr can usually be avoided by using a matching construct instead like [1] https://t3x.org/lfn/church.zipBut then (ATOM NIL) is neither TRUE nor FALSE.
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.
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>.
Many times. A google for "sweet expressions lisp" will give you a bunch of implementations and opinions.
Aha, thanks https://dwheeler.com/readable/
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).