This is an open issue, but we are getting to the point where we need to
think ahead about it.
There are many forms in BitC that are idenfied as "derived forms". This
is a polite way of saying "these would have been macros if we had a
macro system". There exist examples of hygenic macro systems for Haskell
(Template Haskell) and for O'Caml (camlp4, camlp5).
I originally rejected macros for BitC for three reasons:
1. They present some potentially serious impediments to source audit;
the expanders are very easy to get wrong and very hard to
understand. This is more true for a typed language than for LISP;
a macro expander for a typed language remains an AST->AST
transformer, but the definition of an AST is much more complicated.
2. A macro has to "run" somewhere, and this demands compile-time
execution. The question is: what environment does it run in?
The one that is in scope in the program where the macro expander
executes, or an environment supplied by the compiler, or what?
Should a macro-expander be able to call helper procedures that
are defined above it in the program? If so, how eagerly does
polyinstantiation need to run?
Note that this violates separate compilation!
3. Macro systems are closely tied to the AST scheme, and we knew
from the beginning that the lisp-y surface syntax for BitC was
likely to change.
Given the way in which we went about building the prototype compiler,
the potential complexity in [2] was overwhelming. Given the environment
issues that are raised by [2], I am inclined to believe that if we want
a macro system it may be better to think of it as extending the parser
on the fly rather than performing an AST->AST transform.
Because the surface syntax will be changing, we are hitting the point
where we more or less need to take a position on this issue. Any
thoughts that anybody wants to offer on this whole issue? Any pointers
to other schemes that I should look at?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
