Macros

[Matthias Felleisen <matthias@iucs.cs.indiana.edu>]

Here is a final attempt to explain my position on macros and related matters.

I perceive two major purposes for macros:
  1. extending the set of available syntactic facilities
  2. manipulating an s-expression in an arbitrary way and interpreting the
     result as program text at compile time.
I shall call the first kind of facility "extend-syntax", the second kind
"sep" (for s-expression processing).

1. When we extend syntax, we manipulate s-expressions that coincide with
abstract syntax trees. Since these are trees, not graphs, there is NO NEED
WHATSOEVER to use any kind of assignment: assignments exist for creating
circularities and for modeling state (in the sense of objects and state
variables). Therefore, a functional specification of these extensions is
sufficient. Furthermore, the extension of language syntax should be as far
as possible separated from ordinary evaluations although this is subject to
research and compromise. This is---in my eyes, perhaps not Eugene's---the
essence of Eugene's dissertation on extend-syntax. His choice of using 
pattern-matching for the specification of extensions is---for many people---
convenient, but not inherent.

2. The arbitrary manipulation of s-expressions at compile time can mean two
things:
  a: obtaining a value that we cannot write down in Scheme and including it 
     in expansions, e.g. closures. This is actually 
     a problem of Scheme and can be fixed in various ways. A weak solution is
     Eugene's with-construct in extend-syntax which accomplishes this, but
     unfortunately also does other things. (Another solution is to work with a 
     stronger language.)
  b: performing arbitrary and possibly infinite computations. This is the point
     of contention and the Indiana school of thought rejects this possibility.
     We feel the interaction between compile time and run time (or anytime
     computations) is not understood well enough to justify an inclusion 
     in RRRS. Just as there is a better way for expressing extend-syntax
     the community should look for better ways for dealing with these problems.

Old-style macros with no global side-effects can stillbe implemented with
extend-syntax:
(extend-syntax
  (define-macro Macro TransForm) 
  (extend-syntax (Macro exp ...) (eval (Transform '(exp ...))))
[This requires eval and possibly a split of eval into several pahses together with
Dan's favorite (and (in)famous) extend-syntax macro eval-once.]

Because extend-syntax (in whatever form) is simpler and demonstrates to the
world that the Scheme-designers understand the problem and because it can
implement conservative sep-macros, I opt for an extend-syntax-like mechanism 
as a primitive tool.  

-- Matthias  & Bruce.