Re: Issue EVAL-WHEN-NON-TOP-LEVEL, v2

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

I guess what's obvious to me is not obvious to you.  Perhaps an
example might help clarify this. 

    (eval-when (eval compile load)
        (defmacro bar ...))

Suppose we do as you suggest and say that the bodies of top-level
EVAL-WHENs continue to be top-level, but prevent nested EVAL-WHENs
 from doing COMPILE evaluation.  Then, since the macro definition for
BAR is at top-level, it must cause some compile-time magic to happen
when it is compiled (processing for the LOAD situation).  This implies
that you couldn't implement DEFMACRO by expanding it into an EVAL-WHEN,
because the required magic actions would be suppressed.

My claim is that there is really no need for the macro definition of
BAR to cause any compile time magic when it is processed for the LOAD
situation.  After all, BAR has already been fully defined in the
compiler's environment because of the COMPILE situation being
specified in the EVAL-WHEN.  In other words, the multiple evaluation
problem applies just as much to nested defining macros as nested
EVAL-WHENs.  The simplest way to deal with both problems is to just
say that top-level-ness is not passed through to the body at all. 

I think that perhaps people are reading more into the term "top-level"
than it really implies.  Under our current set of proposals, the only
things that top-level-ness is used for are:

   - to determine when it is appropriate to perform compile-time
     side effects for EVAL-WHEN and various defining macros.

   - to apply some constraints on the order of processing.

Also, I have a problem with the example you cite:

>     1. The COMPILE situation "inherits"  -- namely, the following
>        form will cause (blast-off) to be executed in the compiler
>        environment, even though it is wrapped in eval-when(load):
>              (eval-when (eval compile load)
>                (eval-when (load)
>                   (blast-foo)))

Under the current proposal, BLAST-FOO will not be called at compile
time regardless of whether EVAL-WHEN passes through top-level-ness.
(This is because the COMPILE processing for the outer EVAL-WHEN passes
the inner EVAL-WHEN to EVAL, which looks only for the EVAL situation.)
If this is seen as a serious compatibility problem, the only thing I
can see to do about it is go back to describing EVAL-WHEN with a
compile-time-too state variable, as in CLtL, which would fix the
problem with multiple evaluations without messing with the definition
of top-level-ness.  At this point, I'm inclined to agree with Cris
that we ought to try to "fix" the nesting behavior of EVAL-WHEN,
though.

-Sandra
-------