Re: draft of alternate proposal for EVAL-WHEN-NON-TOP-LEVEL

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Tue, 07 Mar 89 11:02:42 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

    I would very much like to see what GENERALIZE-EVAL-NEW-KEYWORDS will
    do to DEFINING-MACROS-NON-TOP-LEVEL before voting for the former.  I
    still want to be able to wrap a LET around a couple of DEFUNs and have
    it all work correctly!

That's difficult to answer, since the last version of
EVAL-WHEN-NON-TOP-LEVEL archived here is version 7, which the compiler
committee said in Kauai they were going to rewrite.  However, here is
the proposal section from version 7, with my comments interleaved.
I will ignore the new-keywords versus keep-the-old-names issue, as
that clearly affects only the appearance of code, not the semantics.
    
    Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
    
    (1) Remove the language from p. 66 of CLtL quoted above.  Clarify that
    while defining macros normally appear at top level, it is meaningful
    to place them in non-top-level contexts and that the compiler must
    handle them properly in all situations.  However, the compile-time side
    effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
    only take place when the defining macros appear at top-level.
    
True under all EVAL-WHEN proposals.

    (2) Remove the language on p. 145 of CLtL, which states that macro
    functions are always defined in the null lexical environment.  Clarify
    that all defining macros which create functional objects (including
    DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
    DEFSETF, as well as DEFUN) must ensure that those functions are
    defined in the lexical environment in which the defining form is
    evaluated.
    
True under all EVAL-WHEN proposals except for the one (no longer extant
I believe) that said that the body of an EVAL-WHEN is executed in the
null lexical environment rather than the lexical environment surrounding
the EVAL-WHEN.

    (3) Define a ``top-level form'' as follows:
    
	- Each form read by COMPILE-FILE from the input file is a top-level 
	  form.
    
	- Forms within the body of a top-level PROGN, EVAL-WHEN, or 
	  COMPILER-LET are also top-level forms.
    
	- The expansion of a top-level macro call is also a top-level form.
    
True under the EVAL-WHEN proposal that I like.  The second bullet is 
false under the EVAL-WHEN proposal that Sandra likes, since the body of
a top-level EVAL-WHEN is not a top-level form under that proposal.

    Top-level forms would be evaluated by the interpreter in a null
    lexical environment, but evaluation in a null lexical environment does
    not necessarily imply that the form is top-level.
    
True under all EVAL-WHEN proposals.

    (4) Specify that top-level forms in a file being compiled are
    guaranteed to be processed sequentially, including forms within the
    body of a top-level PROGN, EVAL-WHEN, or COMPILER-LET.  The order in
    which non-top-level subforms of a top-level form are processed by the
    compiler is explicitly left unspecified.

Not affected by EVAL-WHEN proposals.

So I think the effect on DEFINING-MACROS-NON-TOP-LEVEL is none other
than avoiding breaking it by violating its assumptions about EVAL-WHEN.
Of course if there is a rewritten DEFINING-MACROS-NON-TOP-LEVEL that
I have not seen (I am not on the compiler committee), the story might
be different.