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

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

My earlier "retching" was at the prospect of having EVAL-WHEN use
different rules for deciding when to perform compile-time side-effects
than all of the various defining macros.  I don't think we want to
rule out the use of EVAL-WHEN for implementing those side-effects.  On
the other hand, a few people (notably Pitman) have been quite
insistent that we do not *require* EVAL-WHEN to be used to implement
those side-effects (it ought to be legal for the compiler to treat the
defining macros as "special forms" when they appear at top-level).

That is why I think changing the meaning of "top-level" is the
cleanest solution to the problem.  If you agree with me that EVAL-WHEN
and the defining macros should use the same rules for deciding when to
do compile-time side-effects, then the only other consequence of
top-level-ness is the order of processing issue.  At least in the
(COMPILE LOAD) case, I don't think this ought to cause much of a
problem.  Alternatively, if we have to make an exception somewhere, it
seems like this is the place to make it: say that the bodies of
EVAL-WHENs are not top-level (at least in the (COMPILE LOAD) case) but
the compiler has to process them in order anyway. 

-Sandra
-------