Ever since learning about multistaging, I've never seen the point of macros. I'd imagine that BitC would only want to permit one stage, and using staging has the advantage of retaining important type information.
Staging can also permit a limited form of reflection/polytypism [1]. I suspect that you might consider even a single stage as a tad too ambitious though. :-) Sandro [1] http://okmij.org/ftp/ML/#gprint Jonathan S. Shapiro wrote: > 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
