Re: pattern-matching and programs

[Neel Krishnaswami <address@hidden>]

Kragen Sitaker writes:
> In discussion of macro systems recently, some people have complained
> that pattern-matching macro systems make decomposing macros too hard:
> 
> > When all you've got is simple pattern matching, complex
> > transformations require pages of helper macros. Dylan's FOR loop,
> > for example, requires about 5 pages of dense macrology to support a
> > tiny fraction of the features provided by LISP's LOOP macro.
> 
> (Eric Kidd wrote the above, but others seemed to agree.)
> 
> It discusses a fascinating programming language entirely based on
> pattern-matching; it appears that programming in a language like
> Aardappel would feel a lot like programming in a pure functional
> language. [...]
>
> Could a similar small addition to Dylan's macro-defining sublanguage
> reduce the FOR definition to a reasonable size?

It's not the pattern-matching that makes the macro language hard to
use; it's the order of evaluation of the template substitutions.

The way that Scheme syntax-rules or Dylan define macro works is that
macro expansions are triggered by encountering the name of the macro
in the token stream. Then, each macro is defined as a set of patterns,
and for each pattern you define a template to rewrite the pattern
into. Then the macro expander is rerun on the rewritten code. This
means that the only way to trigger a macro expansion is by filling in
a whole template and re-expanding; there's no way to expand a
subexpression and interpolate it in. Consequently, you can't properly
decompose a macro definition, because you can't break a single macro
definition into smaller, well-defined submacros. :(

Oleg Kiselyov has a really nice description of this problem (and a
solution to it) in his talk "Macros that Compose: Systematic Macro
Programming", at:

  <http://okmij.org/ftp/Scheme/macros.html#Macro-CPS-programming>

-- 
Neel Krishnaswami
neelk@alum.mit.edu