[Resending, because apparently it didn't get through yesterday]
Hi,
this is my first post here. I'm a Lispnik who likes BitC's goals (and
E's) a lot.
Jonathan S. Shapiro wrote:
> 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?
The first language I know to address this confusing issue is R6RS
Scheme; it calls its solution "phase separation". The idea is that
macros run in a completely different environment/phase from the code
they are taking as input.
The actual, user-written code runs at level 0, while macros run at level 1,
macros in the bodies of macros run at level 2, and so on ad infinitum
("reflective tower").
> Should a macro-expander be able to call helper procedures that
> are defined above it in the program?
No, I think this would be extremely confusing and difficult to
implement. In R6RS, an import statement has to explicitly load code
into a higher level to be available there. In (non-R6RS) pseudocode,
for function F from package P to be available inside a macro it has to
be imported into level 1.
(import-package p level: 1)
(defmacro some-macro () ... (f x) ...)
If a normal import (which imports into level 0) were used, F could be
used in the normal code, but not inside the definition of SOME-MACRO.
> If so, how eagerly does
> polyinstantiation need to run?
> Note that this violates separate compilation!
With a R6RS-style phase separation, separate compilation is possible.
Here's the relevant piece from R6RS:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-10.html#node_sec_7.2
This paper by Flatt and Felleisen introduced this system:
Units: Cool Modules for HOT Languages (1998)
http://citeseer.ist.psu.edu/flatt98unit.html
Best regards,
Manuel Simoni
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
