4 ms·
https://github.com/norvig/paip-lisp https://github.com/norvig/paip-lisp - Peter Norvig's Paradigm's of AI Programming https://github.com/norvig/paip-lisp/searc
by Jtsummers 4y ago
https://github.com/norvig/paip-lisp https://github.com/norvig/paip-lisp - Peter Norvig's Paradigm's of AI Programming
https://github.com/norvig/paip-lisp/search?l=Markdown&q=defmacro https://github.com/norvig/paip-lisp/search?l=Markdown&q=defm... - all references to defmacro in the markdown files
Chapter 3 shows a simple macro, just adding a while loop to the language.
Chapter 9 shows some more complex ones, including a with- macro and a grammar compiler macro.
Chapters 11 and 12 show the development of a Prolog implementation in CL using defmacro to aid in compilation again in Chapter 11.
Chapter 12 shows adding an OO system to the language. Technically not needed with CLOS, but a good demonstration of what can be done with macros.
There are other examples (why I included that search link). Macros let you change the language in ways large and small. Many uses could probably be replaced with functions, though you'd end up having to throw a bunch of quotes about or closures in order to delay processing things. You'd also be delaying that to runtime, which incurs its own penalties compared to macro expansion and compile time (if a compiled CL).
- michaelwww 4y agoI like this but it seems like there would be many inconsistencies to building your own language without an actual language specification
- reikonomusha 4y agoSo, as a designer of miniature languages and syntactic extensions, specify it! A well written function must also abide by some promise or specification—contracts on the inputs and invariants on the outputs. I don't see why new syntactic structures are much different from that. I think there's undue spookiness around macros among lots of programmers, especially those who haven't sought to solve some problem with them. - "It's too powerful for the common person." - "It's way too likely to make code confusing." - "It's invariably too hard to reason about." - "It won't work on a team because everybody is going to make their own weird incompatible language and it's just not scalable." All of these sentiments are complete bunk, and I argue are against common wisdom around other programming abstractions, like functions or classes.