Arc Forumnew | comments | leaders | submitlogin
Macros vs Closures: a great LL1 thread from 2002
4 points by akkartik 3808 days ago | 1 comment
"If anyone has good examples of macros that can't be expressed with a convenient notation for closures, it would be interesting to see them. My Smalltalk-hacking friend Trevor Blackwell has often claimed that macros were unnecessary if you had blocks."
== Highlights

Trevor Blackwell's provocative post about places to avoid macros, and a summary of a lot of the examples in the thread:
Its responses are good too. I would be careful using macros for them, but not avoid them entirely. See arc's obj and fallintothis's inittab (

"have all the examples of potentially non-blockable macros so far been cases of punning, treating something as both code and data?"

  (define-syntax assert
    (syntax-rules ()
      ((assert test)
       (if (not test) (assert-error (quote test))))))

Guy Steele's symbolic-differentiation macro:
Reference to how you would do that in smalltalk, but it tellingly doesn't have code:
Three interesting-looking papers from 1984:
Interesting back-story on common lisp's LOOP:
A tantalizing reference to the language-vs-tool tension:
Guy Steele (referring to the assert macro): "Macros let me express the idea that I need only a few relevant line numbers kept around at run time, rather than all of them."

Trevor Blackwell: "I don't believe in adding a complex language feature for small runtime savings."

Meta-programming as code generation vs meta programming as parameterized higher-order functions:
Avi Bryant dissing all before him: "Now, I know there are better examples out there, I just want somebody to bring them up. The best I can do right now is the typical with-html macros people use for generating markup - I've never been able to satisfactorily replace those in Smalltalk or Ruby."
Finally, Guy Steele echoing PG's opinion on brevity:
Reading all this, my conclusion is that if you don't care as much about terseness (like Trevor Blackwell) you probably won't have as much use for macros.


Parent thread that spawned this one:

4 points by rocketnia 3807 days ago | link

I think it comes down to compile-time optimization and code reuse.

Lisp-like macros let you take code you've written and use it as data during an arbitrary compile-time calculation (which might give you code again), which you have to define. If you also want to use the compiler's own cleverness in your computation, you need another leap of technology, such as hygienic macros or some kind of explicit compiler access within the macro code.

Lambda syntax lets you take code you've written and use it as a function value, with the compilation of that function happening during compile time using the compiler's existing cleverness... and nothing but that.

Quote syntax (as well as fexprs in general) lets you take code you've written use it as data, but it does little to assure you that any of that computation will happen at compile time. If you want some intensive calculation to happen at compile time, you have to do it in a way you know the compiler (as well as any compiler-like functionality you've defined) will be nice enough to constant-propagate and inline for you.

If you don't need compile-time guarantees, then quote syntax is enough. If you're only going to reuse code as code, then lambda syntax may be enough, depending on your definition of code. If you're going to reuse code as non-code (from the compiler's perspective) and you want it compiled anyway, macros are a way to do that.

In the case of Arc, the compile time guarantee advantage is a bit flimsy considering everything's interpreted anyway, but Arc's macro system at least gives a loading time guarantee, which ought to be pretty similar for the purposes of long-running server applications.