Issue EVAL-WHEN-NON-TOP-LEVEL

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

> Date: Thu, 23 Feb 89  17:07:24 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> (1) It is not obvious why the body of the outer (EVAL-WHEN (COMPILE) ...)
> should not be considered to be top level. 

To some extent I think this is really just an arbitrary decision.  Most of the
different variations on whether EVAL-WHEN passes top-level that I've thought
about can be made to work.  Its just a matter of what situations you then have
to include when writing your EVAL-WHENs so that they will work right, with some
choices on the pass-through producing requirements which are more intuitive
than others (though there is sometimes argument about which are more
intuitive). 

> (2) The primary reason that person 1 used EVAL-WHEN was that they wanted it
> to happen at compile time; considerations of top-level-ness is a secondary
> detail.  Person 2 also wants it to happen at compile time.  So this appears
> to be a case of two rights make a wrong. 

Consider the case of a DEFMACRO, which expands into an EVAL-WHEN COMPILE to
record the expander in the remote environment and a form which calls SETF of
MACRO-FUNCTION when the file is loaded.  If you wrap an EVAL-WHEN COMPILE
around this, there is probably no point in recording the expander in the remote
environment, since it is about to be defined in the local environment.

kab
-------