[iterate-devel] bug report

[Hoehle, Joerg-Cyril]

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.