[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> Date: Wed, 5 Oct 88  14:07:38 CDT
> From: David N Gray <Gray@DSG.csc.ti.com>
> This alternative might appear more attractive if it were clarified that
> the "compatibility problems" only apply to macros used within function
> definitions contained in the body since they are not executed during
> execution of the COMPILER-LET.

No, there are other cases as well.  Consider this one:

    (eval-when (eval compile load)
        (defvar *silly* nil)
        (defmacro silly-macro () `(quote ,*silly*)))

    (let ((*silly*  (cons 'let *silly)))
        (compiler-let ((*silly* (cons 'compiler-let *silly*)))

If the interpreter performs evaluation in parallel with macro expansion, 
then SILLY-MACRO will see the value of *SILLY* as (COMPILER-LET LET),
but in the compiler (or a preprocessing interpreter) it will only see it
as (COMPILER-LET).  Of course, similar problems can occur when macros
rely the values of special variables, even when COMPILER-LET is not

You're right, though -- the writeup should go into more detail on this.

> I'm leaning in favor of a variation of this approach that would say that
> if an implementation does not normally do a preprocessing code walk, then
> the evaluator's implementation of COMPILER-LET needs to do a macro
> expansion code walk on its body forms before evaluating them.  We
> currently do macro expansion as needed during evaluation, yet it would be
> a trivial change to have COMPILER-LET invoke MACROEXPAND-ALL on its body.
> This should only be a hardship for any implementation that doesn't do a
> pre-pass and doesn't already have a MACROEXPAND-ALL.

I suspect that most implementations that don't do a code-walking prepass
in the interpreter don't have anything like MACROEXPAND-ALL, either, so
this may not really buy anything.  I suppose this could be presented as
yet another alternative in the next iteration of the writeup on this
issue.  Does anybody else like this idea?