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

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

> Date: Mon, 9 Jan 89 20:14:56 PST
> From: Jon L White <jonl@lucid.com>
> 
> Say, didn't you realize that the COMPILE situation in the outter eval-when
> means that the DEFMACRO will be evaluated at compile time, regardless of
> any nested inner eval-when's?  You know that I favor an implementaiton
> of DEFMACRO that simply macroexpands onto usages of EVAL-WHEN, so that 
> there is only *one* notion of toplevel "magic" --namlely eval-when.

Yes, of course I realized that.  That's why I've been arguing that
EVAL-WHEN does -not- need to pass top-level-ness on to its subforms --
so that EVAL-WHEN and the defining macros will be *defined* to have
the same behavior re multiple compile-time evaluations when nested
inside of an (EVAL-WHEN (COMPILE LOAD) ...).

If you'll please look at issue DEFINING-MACROS-NON-TOP-LEVEL, it is
not a requirement that defining macros expand into EVAL-WHENs.
(Pitman and others have argued strongly against even *recommending*
this.)  What it does require is that the defining macros perform their
compile-time side effects **only when they appear at top-level**.  

If we change the requirements for when EVAL-WHEN does compile-time
magic without changing the requirements for defining macros, then
using EVAL-WHEN to implement the defining macros would not be a
legitimate implementation technique. 

Changing the definition of what top-level is will take care of the the
EVAL-WHEN problem and will also allow you to implement the defining macros
in terms of EVAL-WHEN.

The only other thing that top-level-ness implies is the order of
processing of subforms.  So far, nobody has been able to come up with
an example that will break for this reason. 
	
-Sandra
-------