3 ms·

Gödel, Escher, Elisp: The Beauty of Macros

106 points by JNRowe 2mo ago

KeenanKeenan 2mo ago
If macros can implement arbitrary language features then how come elisp has never built a type system?
- deleted 2mo ago
  [deleted]
- wk_end 2mo ago
  Well, not elisp, but https://coalton-lang.github.io https://coalton-lang.github.io or maybe https://shen-language.github.io https://shen-language.github.io
  - KeenanKeenan 2mo ago
    Typed racket too, might I add. I just imagine static typing around stable core APIs would help users understand how eglot and vertico compare to prior art. The way I learned how the completion stack works was to ask claude to show me what the elisp entrypoints would look like if implemented in typescript. It's not because I'm unfamiliar with lisp, I'm not, it's just easier to reason with the world in terms of data structures and their contracts.
  - anthk 2mo ago
    CL is the big cousin of Elisp, almost.
- BeetleB 2mo ago
  I would expect you can. lexilambda created Typed Racket on top of Racket. https://github.com/racket/typed-racket https://github.com/racket/typed-racket
  - ashton314 2mo ago
    Another approach, using macro expansion to perform the type checking: https://docs.racket-lang.org/turnstile/ https://docs.racket-lang.org/turnstile/ Turnstile relies on the fact that in Racket, you can have identifier macros [1] which can be expanded in pretty much any location (except binding, naturally). Racket is unique in this regard. Clojure has a mechanism to get roughly the same thing, but it's complicated. [2] 1: https://docs.racket-lang.org/guide/pattern-macros.html#%28part._.Identifier_.Macros%29 https://docs.racket-lang.org/guide/pattern-macros.html#%28pa... 2: https://lambdaland.org/files/2024_ecoop_type_tailoring.pdf https://lambdaland.org/files/2024_ecoop_type_tailoring.pdf
- iLemming 2mo ago
  [flagged]
- drob518 2mo ago
  https://typedclojure.org/ https://typedclojure.org/
- hayley-patton 2mo ago
  > If macros can implement arbitrary language features Not really your question--others have provided examples of type systems as macros--but they can't, they can only do local rewrites. You couldn't, for example, express mutation or non-local control flow if you didn't have them already; On the expressive power of programming languages [0] is rather theoretical but does set out the boundary of what macros can and can't do. That they're local means everyone has to buy into your type system if you want it to be a macro, though. [0] https://www.sciencedirect.com/science/article/pii/016764239190036W https://www.sciencedirect.com/science/article/pii/0167642391... though https://www.youtube.com/watch?v=43XaZEn2aLc https://www.youtube.com/watch?v=43XaZEn2aLc might be a useful walkthrough of the ideas being presented
kimi 2mo ago
Remember the golden rule of Lisp macros: don't write a macro.
- hencq 2mo ago
  Meh, that seems to be a bit of a clojure thing. In the Racket world, with hygienic macros and phase separation, they'll routinely write macros returning macros, etc.
  - drob518 2mo ago
    Macros returning macros happens in every Lisp, including Clojure. It’s no biggie. Hygiene has nothing to do with it and there are ways of properly managing unique symbols in all Lisps, even if some dialects are more manual than in Scheme/Racket.
    - hencq 2mo ago
      I know, but the point is that in Clojure there's a bit of a culture of not writing macros unless you have to, while in Racket there's no such thing. Agreed that you can write macros just fine in other lisps.
      - drob518 2mo ago
        The Clojure community is definitely less macro-crazy than other Lisp communities. But it’s also very programmer-specific. I’ve worked on OSS Clojure code where the original programmer loved macros. In general, I found it more annoying because reading through recursive macros is just more difficult than reading a simple function. So, I think it’s better for the community to de-emphasize macros, in general. Even if I want back to programming in CL or Scheme/Racket, I think I’d be much more judicious about using macros. Again, nothing against macros in general. They are a powerful tool in Lisp. But, to quote Spider-Man, with great power comes great responsibility.
- chiply 2mo ago
  Author here. I think in general this is sound advice, but in Emacs it is an incredibly convenient utility. I use them all the time. Mostly simple things like wrapping function definitions, or even other macros that wrap function definitions. Most of my lisp experience is in Emacs where the config layer is essentially exposed through an elisp API. In that context, I find myself using macros a lot. But if I was building some software from scratch, like say a data processing system, I can't immediately think of scenarios where I would define macros. Worth mentioning in Elisp that even if you don't define your own macros, you use them more often than you would think. defun, unless, def-custom, etc (more examples in the blog post) are all macros. The fact they look and feel like non-macros like special forms and built in functions implemented in C is part of what makes elisp so cool to me. There are plenty of homoiconic languages, but you rarely feel the distinction between program and data in elisp, and macro-supporting lisps in general.
meken 2mo ago
> To anticipate a common question: why couldn't my-unless be a function? Function arguments are evaluated eagerly, before the function ever sees them. Interesting, so if you’re using a lazy language then you don’t need a macro here and could write my-unless as a function.
- wk_end 2mo ago
  Indeed: https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Control-Monad.html#v:unless https://hackage-content.haskell.org/package/base-4.22.0.0/do...
- brabel 2mo ago
  Yes, the D language has that as a feature in function arguments! https://dlang.org/articles/lazy-evaluation.html https://dlang.org/articles/lazy-evaluation.html It makes it hard to know when things run. In Lisp you also have that problem everywhere, of course. As the post shows this allows you to do stuff that looks like extending the syntax of the language. I can’t decide if I love it or hate it!
  - carlosneves 2mo ago
    Props to D for having such a simple implementation of fexprs[1]. The downside compared to macros I think is that, as argument expressions become lambdas, it becomes harder to manipulate them. Check the cond example which needs two fexprs, whereas one macro could do it. Not sure about D, but if it were lisp, even lambdas could be manipulated as lists. Macro args not having the lambda wrapping just seems simpler. [1] https://en.wikipedia.org/wiki/Fexpr https://en.wikipedia.org/wiki/Fexpr
    - brabel 2mo ago
      Walter Bright is against adding macros to D but D already has really advanced metaprogramming in other shapes: https://dlang.org/spec/template-mixin.html https://dlang.org/spec/template-mixin.html https://dlang.org/spec/traits.html https://dlang.org/spec/traits.html
- 2mo ago
deleted 2mo ago
[deleted]
thisisauserid 2mo ago
I always thought it odd that Penrose gets dropped from the Escher conversations.
- mangodrunk 2mo ago
  Can you elaborate? Roger Penrose and his father Lionel did independently discover and popularize the Penrose Stairs and Penrose Triangle but Oscar Reutersvärd had created both years earlier. What do you think should be said about Penrose?
  - chiply 2mo ago
    Yeah, I think the story is that Penrose saw an illusion in an Escher print that encouraged him to create the Penrose Triangle, his dad Lionel created the Penrose staircase, and then sent a copy of these in the paper "Impossible objects..." to Escher, who then used the staircase in "Ascending and Descending" and others. It's kind of cool that they cite eachother in these works as inspiration here. I bet Escher could have made an interesting print of them pointing at one another in some kind of impossible object. And apparently neither Penrose nor Escher knew about Oscar Reutersvärd's work! Oscar got robbed lol.
    - mangodrunk 2mo ago
      Yeah, it’s odd that Escher didn’t respond to Reutersvärd’s letters. Also, Penrose found out about Reutersvärd’s work in 1984: >It wasn’t until 1984 that Roger Penrose (whose father Lionel died in 1972) discovered that Oscar Reutersvärd had invented the triangle and the stairs much earlier. https://escherinhetpaleis.nl/en/about-escher/escher-today/oscar-reutersvard https://escherinhetpaleis.nl/en/about-escher/escher-today/os...
  - thisisauserid 2mo ago
    In 1954, Escher inspired Roger Penrose to create the impossible triangle. Roger shared this with his father, Lionel, who then designed the impossible staircase. In 1958, they published a paper on these illusions and sent a copy to Escher. Escher used Lionel's staircase to create Ascending and Descending and Roger's triangle to create Waterfall. Both Penrose and Escher were completely unaware that Oscar Reutersvärd had independently invented these shapes earlier.
anthk 2mo ago
The Computational Beauty of Nature it's similar and it has the code of the book there: https://github.com/gwf/CBofN https://github.com/gwf/CBofN Some tools might crash X under CWM for OpenBSD, switch to FVWM or use some tool like mimalloc. On Lisp, the book basically builds integers based on conses, kinda like Peano Axioms.
bossyTeacher 2mo ago
Why is most AI work done in Lisp? There are many reasons, most of which are somewhat technical, but one of the best is quite simple: Lisp is crisp. Or as Marilyn Monroe said in The Seven-Year Itch, "I think it's just elegant!" This claim didn't age well.
- chiply 2mo ago
  Haha, this is very true. Symbolic AI is dead for the most part, but I feel like it was an issue of labor scale. There weren't enough code fluent humans to embed all the knowledge. I do think symbolic AI will see a resurgence though. I could see it being a part of enrichment to current models. I don't think it's the case that we'll see diminishing returns THEN reach for symbolic AI. I think that adding a symbolic layer could greatly enhance their effectiveness today and make the models cheaper (by being performant with fewer params and therefore cheaper to run and serve). You already kind of see clues of this as creating graphs / ontologies as part of a RAG or retrieval phase are proven to improve performance of these AI models in specific domains. At the same time, back then the thought was that symbolic AI was the answer, and for sure Hofstadter's understanding of intelligence, and the emergence of consciousness from matter, had everything to do with symbols. He's talked about this, very interesting, although this is not a 'feel good' artifact from the Hofstadter canon lol. https://www.youtube.com/watch?v=R6e08RnJyxo&t=227s https://www.youtube.com/watch?v=R6e08RnJyxo&t=227s

106 points by JNRowe 2mo ago

KeenanKeenan 2mo ago

If macros can implement arbitrary language features then how come elisp has never built a type system?

deleted 2mo ago
[deleted]
wk_end 2mo ago
Well, not elisp, but https://coalton-lang.github.io https://coalton-lang.github.io or maybe https://shen-language.github.io https://shen-language.github.io
- KeenanKeenan 2mo ago
  Typed racket too, might I add. I just imagine static typing around stable core APIs would help users understand how eglot and vertico compare to prior art. The way I learned how the completion stack works was to ask claude to show me what the elisp entrypoints would look like if implemented in typescript. It's not because I'm unfamiliar with lisp, I'm not, it's just easier to reason with the world in terms of data structures and their contracts.
- anthk 2mo ago
  CL is the big cousin of Elisp, almost.
BeetleB 2mo ago
I would expect you can. lexilambda created Typed Racket on top of Racket. https://github.com/racket/typed-racket https://github.com/racket/typed-racket
- ashton314 2mo ago
  Another approach, using macro expansion to perform the type checking: https://docs.racket-lang.org/turnstile/ https://docs.racket-lang.org/turnstile/ Turnstile relies on the fact that in Racket, you can have identifier macros [1] which can be expanded in pretty much any location (except binding, naturally). Racket is unique in this regard. Clojure has a mechanism to get roughly the same thing, but it's complicated. [2] 1: https://docs.racket-lang.org/guide/pattern-macros.html#%28part._.Identifier_.Macros%29 https://docs.racket-lang.org/guide/pattern-macros.html#%28pa... 2: https://lambdaland.org/files/2024_ecoop_type_tailoring.pdf https://lambdaland.org/files/2024_ecoop_type_tailoring.pdf
iLemming 2mo ago
[flagged]
drob518 2mo ago
https://typedclojure.org/ https://typedclojure.org/
hayley-patton 2mo ago
> If macros can implement arbitrary language features Not really your question--others have provided examples of type systems as macros--but they can't, they can only do local rewrites. You couldn't, for example, express mutation or non-local control flow if you didn't have them already; On the expressive power of programming languages [0] is rather theoretical but does set out the boundary of what macros can and can't do. That they're local means everyone has to buy into your type system if you want it to be a macro, though. [0] https://www.sciencedirect.com/science/article/pii/016764239190036W https://www.sciencedirect.com/science/article/pii/0167642391... though https://www.youtube.com/watch?v=43XaZEn2aLc https://www.youtube.com/watch?v=43XaZEn2aLc might be a useful walkthrough of the ideas being presented

kimi 2mo ago

Remember the golden rule of Lisp macros: don't write a macro.

hencq 2mo ago
Meh, that seems to be a bit of a clojure thing. In the Racket world, with hygienic macros and phase separation, they'll routinely write macros returning macros, etc.
- drob518 2mo ago
  Macros returning macros happens in every Lisp, including Clojure. It’s no biggie. Hygiene has nothing to do with it and there are ways of properly managing unique symbols in all Lisps, even if some dialects are more manual than in Scheme/Racket.
  - hencq 2mo ago
    I know, but the point is that in Clojure there's a bit of a culture of not writing macros unless you have to, while in Racket there's no such thing. Agreed that you can write macros just fine in other lisps.
    - drob518 2mo ago
      The Clojure community is definitely less macro-crazy than other Lisp communities. But it’s also very programmer-specific. I’ve worked on OSS Clojure code where the original programmer loved macros. In general, I found it more annoying because reading through recursive macros is just more difficult than reading a simple function. So, I think it’s better for the community to de-emphasize macros, in general. Even if I want back to programming in CL or Scheme/Racket, I think I’d be much more judicious about using macros. Again, nothing against macros in general. They are a powerful tool in Lisp. But, to quote Spider-Man, with great power comes great responsibility.
chiply 2mo ago
Author here. I think in general this is sound advice, but in Emacs it is an incredibly convenient utility. I use them all the time. Mostly simple things like wrapping function definitions, or even other macros that wrap function definitions. Most of my lisp experience is in Emacs where the config layer is essentially exposed through an elisp API. In that context, I find myself using macros a lot. But if I was building some software from scratch, like say a data processing system, I can't immediately think of scenarios where I would define macros. Worth mentioning in Elisp that even if you don't define your own macros, you use them more often than you would think. defun, unless, def-custom, etc (more examples in the blog post) are all macros. The fact they look and feel like non-macros like special forms and built in functions implemented in C is part of what makes elisp so cool to me. There are plenty of homoiconic languages, but you rarely feel the distinction between program and data in elisp, and macro-supporting lisps in general.

meken 2mo ago

> To anticipate a common question: why couldn't my-unless be a function? Function arguments are evaluated eagerly, before the function ever sees them. Interesting, so if you’re using a lazy language then you don’t need a macro here and could write my-unless as a function.

wk_end 2mo ago
Indeed: https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Control-Monad.html#v:unless https://hackage-content.haskell.org/package/base-4.22.0.0/do...
brabel 2mo ago
Yes, the D language has that as a feature in function arguments! https://dlang.org/articles/lazy-evaluation.html https://dlang.org/articles/lazy-evaluation.html It makes it hard to know when things run. In Lisp you also have that problem everywhere, of course. As the post shows this allows you to do stuff that looks like extending the syntax of the language. I can’t decide if I love it or hate it!
- carlosneves 2mo ago
  Props to D for having such a simple implementation of fexprs[1]. The downside compared to macros I think is that, as argument expressions become lambdas, it becomes harder to manipulate them. Check the cond example which needs two fexprs, whereas one macro could do it. Not sure about D, but if it were lisp, even lambdas could be manipulated as lists. Macro args not having the lambda wrapping just seems simpler. [1] https://en.wikipedia.org/wiki/Fexpr https://en.wikipedia.org/wiki/Fexpr
  - brabel 2mo ago
    Walter Bright is against adding macros to D but D already has really advanced metaprogramming in other shapes: https://dlang.org/spec/template-mixin.html https://dlang.org/spec/template-mixin.html https://dlang.org/spec/traits.html https://dlang.org/spec/traits.html
2mo ago

deleted 2mo ago

[deleted]

thisisauserid 2mo ago

I always thought it odd that Penrose gets dropped from the Escher conversations.

mangodrunk 2mo ago
Can you elaborate? Roger Penrose and his father Lionel did independently discover and popularize the Penrose Stairs and Penrose Triangle but Oscar Reutersvärd had created both years earlier. What do you think should be said about Penrose?
- chiply 2mo ago
  Yeah, I think the story is that Penrose saw an illusion in an Escher print that encouraged him to create the Penrose Triangle, his dad Lionel created the Penrose staircase, and then sent a copy of these in the paper "Impossible objects..." to Escher, who then used the staircase in "Ascending and Descending" and others. It's kind of cool that they cite eachother in these works as inspiration here. I bet Escher could have made an interesting print of them pointing at one another in some kind of impossible object. And apparently neither Penrose nor Escher knew about Oscar Reutersvärd's work! Oscar got robbed lol.
  - mangodrunk 2mo ago
    Yeah, it’s odd that Escher didn’t respond to Reutersvärd’s letters. Also, Penrose found out about Reutersvärd’s work in 1984: >It wasn’t until 1984 that Roger Penrose (whose father Lionel died in 1972) discovered that Oscar Reutersvärd had invented the triangle and the stairs much earlier. https://escherinhetpaleis.nl/en/about-escher/escher-today/oscar-reutersvard https://escherinhetpaleis.nl/en/about-escher/escher-today/os...
- thisisauserid 2mo ago
  In 1954, Escher inspired Roger Penrose to create the impossible triangle. Roger shared this with his father, Lionel, who then designed the impossible staircase. In 1958, they published a paper on these illusions and sent a copy to Escher. Escher used Lionel's staircase to create Ascending and Descending and Roger's triangle to create Waterfall. Both Penrose and Escher were completely unaware that Oscar Reutersvärd had independently invented these shapes earlier.

anthk 2mo ago

The Computational Beauty of Nature it's similar and it has the code of the book there: https://github.com/gwf/CBofN https://github.com/gwf/CBofN Some tools might crash X under CWM for OpenBSD, switch to FVWM or use some tool like mimalloc. On Lisp, the book basically builds integers based on conses, kinda like Peano Axioms.

bossyTeacher 2mo ago

Why is most AI work done in Lisp? There are many reasons, most of which are somewhat technical, but one of the best is quite simple: Lisp is crisp. Or as Marilyn Monroe said in The Seven-Year Itch, "I think it's just elegant!" This claim didn't age well.

chiply 2mo ago
Haha, this is very true. Symbolic AI is dead for the most part, but I feel like it was an issue of labor scale. There weren't enough code fluent humans to embed all the knowledge. I do think symbolic AI will see a resurgence though. I could see it being a part of enrichment to current models. I don't think it's the case that we'll see diminishing returns THEN reach for symbolic AI. I think that adding a symbolic layer could greatly enhance their effectiveness today and make the models cheaper (by being performant with fewer params and therefore cheaper to run and serve). You already kind of see clues of this as creating graphs / ontologies as part of a RAG or retrieval phase are proven to improve performance of these AI models in specific domains. At the same time, back then the thought was that symbolic AI was the answer, and for sure Hofstadter's understanding of intelligence, and the emergence of consciousness from matter, had everything to do with symbols. He's talked about this, very interesting, although this is not a 'feel good' artifact from the Hofstadter canon lol. https://www.youtube.com/watch?v=R6e08RnJyxo&t=227s https://www.youtube.com/watch?v=R6e08RnJyxo&t=227s