Re: Issue: EVAL-WHEN-NON-TOP-LEVEL (Version 5)

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

I don't have any quibble with the behavior of the examples you cite.
However, you still haven't said anything to justify the behavior of
your proposal under example *I* cited in my previous message, namely,
why

    (eval-when (load)
        (defmacro foo ...))

should cause FOO to be defined in the compile-time environment even when
the user explicitly specified that the macro only needs to be defined at
load time.

Basically, the problem with the nesting behavior specified by your
proposal and by CLtL is that it provide for any way for the programmer
"turn off" the compile-time behavior of any of the various defining
macros like DEFMACRO, or of nested EVAL-WHENs.  The proposal we were
working on before would make the behavior of the COMPILE situation
analagous to that of the EVAL and LOAD situations: if an outer
EVAL-WHEN doesn't specify the situation, then its body is ignored
under the context that pays attention to that situation, even if it
contains nested EVAL-WHENs that -do- specify that situation. 

If there were a simple fix to your proposal that would change only
this aspect of the nesting behavior, I'd go ahead and propose that.
But to me it seems like you would have to introduce another state
variable (called NEVER-COMPILE-TIME-TOO or something like that), to
indicate whether the COMPILE situation should be ignored, and things
would get even more complicated.  On the other hand, this nesting
behavior falls right out of the other proposal.

Incidentally, RAM's old "Compiler Proposal #3" proposed making a
similar change to the nesting behavior of EVAL-WHEN.  Although he
would have replaced EVAL-WHEN with three new special forms, the one
corresponding to (LOAD EVAL) also inhibited any compile-time
evaluation of subforms. 

-Sandra
-------