Re: how expressive are they?

[address@hidden]

In a message dated 11/22/2002 5:44:59 PM Eastern Standard Time, avi@beta4.com writes:

> The argument I'm still hoping to hear is "macros are more expressive
> *than closures*", and in particular, than a lightweight lambda syntax like
> that provided by Smalltalk.  Unfortunately (like most of 
> the posts in this
> thread) these are the wrong examples:

Personally, what *fails* about the examples I've seen in this thread is that their implementation as a macro would be a single (or few) lines. These are all really simple examples. Making the implementation less opaque at this level does not really hammer home that the implementation of some of these with blocks *is* less opaque-- and a bad thing.

For a slightly more interesting example, I'd be interested in seeing a recursive binding construct like letrec done "at the user level" but without macros.

Two larger-scale examples of using macros can be found in PLT Scheme: the unit and class macros. The first, a module-like construct for dynamically-linked components-- allowing mutally recursive bindings. (And units-with-signatures are implemented as macros on top of the basic unit macros.) The second, a Java-ish class mechanism. Probably this could be simulated using only lambdas, but I doubt that such would scale to real application development.

[Additionally, there is a paper by Kent Dybvig and Oscar Waddell showing some other interesting examples of using macros to define various module facilities in Scheme-- http://www.cs.indiana.edu/~dyb/papers/popl99.ps.gz]

But if you really want to test whether Smalltalk's blocks can do this kind of stuff, knock yourself out. It would be really interesting to see larger scale efforts to do with blocks what Schemers do with macros ;)

Also, as Paul Graham noted, macros are very useful for language designers. Even if one exposed only a language with out macros to the PLT user, their macro system lets the PLT language designers add such complex language constructs (e.g. classes and units) without touching the implementation of MzScheme.

Jim Bender

p.s. A rather different example is the macros used in Oleg Kiselyov's SSAX parser to instantiate XML parsers (based on a set of application specific "handlers"). The result of macro expansion is a parser specialized for the handlers supplied by the application (each is a handler name plus a lambda). On the surface, what Oleg does currently can be done with a function-- Mike Sperber's port of SSAX to R5RS Scheme is one example. But I suspect that the result of Oleg's make-parser macro is more easily optimized by a compiler. As well, Oleg has mentioned the possibility of more aggressive partial evaluation within the implementation of the make-parser macros.

p.p.s. Does a lazy language with an already more concise notation for lambda expressions need macros? Have a look at "Template Haskell": http://research.microsoft.com/Users/simonpj/papers/meta-haskell/meta-haskell.ps