Hi, Larry D'Anna wrote:
It doesn't need to be able to update the environment because it can see for itself that foo is a function, not a macro. This is the case that cannot be handled portably:
(defmacro foo () ''macro) (defmacro bar (form &environment env) (macroexpand form env)) (iter (for i from 1 to 1) (labels ((foo () 'labels)) (return (bar (foo)))))
You're both right. In fact, I like the above "bar" macro so much that I've added a variation of it to the testsuite (not yet in Darcs). I view it as the canonical representative of a foreign macro which depends on macroexpansion and environments to work -- which no code-rewriter can provide portably (at least it's a common belief). I've been wondering whether other approaches, possibly based on two passes through the code could lead to interesting results. Or sort of CPS style, e.g. have the implementation provide the environment, as in (macroexpand `(labels ((foo ...)) (iter-continuation-macro)) env) Iter-continuation-macro would then be invoked with an environment consisting of the addition of the initial env and the foo local function. Sounds interesting, except that MACROEXPAND would stop at the LABELS form... And that would still not tell me how to walk EVAL-WHEN right (another topic). Thanks, Jorg Hohle.