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

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

> (eval-when (load)
>   (eval-when (compile load eval)
>     (some-action)))
>     
> I claim that this case, as described in CLtL, does "some-action" at
> compile-time despite the request of the user of def-xxx-macro and
> despite appearances.  So once again, does anyone know
> of reasons why the inner EVAL-WHEN should in effect override
> the outer one?

I agree that this example behaves the way you describe.  As I
understand it, you'd like to see the absence of the COMPILE situation
in an outer EVAL-WHEN prevent compile-time evaluation resulting from
any nested EVAL-WHENs, right?

Interestingly enough, in an earlier message JonL suggested that the
*presence* of the COMPILE situation in an outer EVAL-WHEN should
prevent compile-time evaluation of nested EVAL-WHENs (to prevent
multiple evaluations).  This suggests a simple solution that would
address both problems: simply change the definition of "top-level" so
that EVAL-WHEN *never* passes top-level-ness on to its body forms. 

Doing this would be an incompatible change from the behavior specified
in CLtL, where wrapping a form in an (EVAL-WHEN (EVAL LOAD)...) is
essentially a no-op.  I have rather mixed feelings about this; on the
one hand the behavior you want cannot be expressed using the current
definition and the change does have some appeal because of its
simplicity, but on the other hand it may break some user code.

Anybody else have thoughts on this?

-Sandra
-------