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

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

chiply.dev

Post reply on HN
Print view View original

31–40 of 44 posts

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

#31

Post by iLemming »

drob518 wrote: post #27
iLemming wrote: post #23

Earlier quoted context omitted.

That is badly generalized proverb. Clojure has unhygienic macros, no expander extension points, and no error-message layer, so "don't" is a rational default there. Yet, for example Racket writes macros that write macros as a matter of course. And that's because the language has the infrastructure: hygiene by default, phase separation, `syntax-parse` with grammar-quality error messages, a module system that actually k…

My own personal rule is that every Lisp programmer should understand macros and very rarely reach for them. They are a super-power, but easy to misuse. I think Paul Graham is partly responsible for the “Lisp = macros” thinking and the general overuse of them. On Lisp was a great book but it does lots of things I wouldn’t consider good practice today. After Graham popularized Lisp and macros, there was a period when e…

I don't think Paul ever envisioned Lisp evolving into something like Clojure, where macros indeed are a bit less than a first-class citizen. And I think the whole adage of "First rule of macro club - don't write macros. Second rule of macro club - don't dispute the first rule...", etc. became a thing only with Clojure. I don't disagree with you - genuine use cases for macros are uncommon. Yet it's an instrument - nothing's wrong with using it properly. Knowing when and how is a skill, experienced Lispers indeed - rarely reach for it.

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

#32

Post by mangodrunk »

chiply wrote: post #19
mangodrunk wrote: post #16

Earlier quoted context omitted.

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?

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 h…

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/os...

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

#33

Post by thisisauserid »

mangodrunk wrote: post #16
thisisauserid wrote: post #12

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

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?

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.

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

#34

Post by downut »

kimi wrote: post #3

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

Ok, common-lisp newbie here.

Could you explain why Paul Graham's book "On Lisp" is wrong? Or misguided? Or misunderstood by newbies like me? 30 years of c++ with a lot of dealing with templates and I'm not feeling the mandatory function purity here.

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

#35

Post by floxy »

downut wrote: post #34
kimi wrote: post #3

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

Ok, common-lisp newbie here. Could you explain why Paul Graham's book "On Lisp" is wrong? Or misguided? Or misunderstood by newbies like me? 30 years of c++ with a lot of dealing with templates and I'm not feeling the mandatory function purity here.

I don't think that is a reasonable request for a response to a comment post, but in my experience, many lisp macro advocates come from other procedural / OO languages and aren't well acquainted with other programming paradigms, so they don't generally know what the don't know about other styles, say functional programming, and how to solve problems using higher order functions, etc. instead of reaching for macros. Which is OK. Not everyone has to become a programming language dilettante.

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

#36

Post by hencq »

drob518 wrote: post #28
hencq wrote: post #13

Earlier quoted context omitted.

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.

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.

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.

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

#37

Post by brabel »

carlosneves wrote: post #24
brabel wrote: post #11

Earlier quoted context omitted.

Yes, the D language has that as a feature in function arguments! 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!

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] h…

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/traits.html

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

#38

Post by BoingBoomTschak »

meken wrote: post #4

> 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.

Unless laziness is pervasive (I guess, no knowledge about GHC internals), you basically have an FEXPR (https://en.wikipedia.org/wiki/Fexpr) which was replaced by macros for good reasons.

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

#39

Post by chiply »

bossyTeacher wrote: post #30

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.

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

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

#40

Post by hayley-patton »

KeenanKeenan wrote: post #2

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

> 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/0167642391... though https://www.youtube.com/watch?v=43XaZEn2aLc might be a useful walkthrough of the ideas being presented

Post reply on HN