Re: Issue COMPILER-LET-CONFUSION, version 1

[David N Gray <Gray@DSG.csc.ti.com>]

> Proposal COMPILER-LET-CONFUSION:CLARIFY-STATUS-QUO:
...
>   Mention that there may be compatibility problems between compiled and
>   interpreted code if the interpreter performs macroexpansion in
>   parallel with evaluation.

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.  For example, if MOO is a macro, then in

  (COMPILER-LET ((*MOO-FLAG* T))
    (MOO ...)
    (DEFUN FOO (...)
      (MOO ...)) )

the macro expansion of the first use of MOO will be able to access the
binding of *MOO-FLAG* on any implementation, but the second use of MOO
cannot portably depend on *MOO-FLAG*.

> Proposal COMPILER-LET-CONFUSION:REQUIRE-PREPASS:
> 
>   Disallow interpreters from performing macroexpansion concurrently with
>   evaluation.  Macroexpansion must be performed in a preprocessing
>   codewalk.

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.