Issues: DEFINING-MACROS-NON-TOP-LEVEL, EVAL-WHEN-NON-TOP-LEVEL, COMPILED-FUNCTION-REQUIREMENTS

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

    Date: Tue, 24 Jan 89 22:13 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    We have a lot to say on these three topics but I've run out of time.  I'm
    just sending this note so you know to expect something on these three,
    most likely on Wednesday or Thursday of this week.

I haven't had time to do much Common Lisp stuff since Tuesday, so "there
will a short delay".

On EVAL-WHEN-NON-TOP-LEVEL, I prefer a proposal by KMP that you haven't seen
yet which is still being debugged.

DEFINING-MACROS-NON-TOP-LEVEL has some minor problems with which forms
have top-level bodies (I agree with IIM that MACROLET and SYMBOL-MACROLET
should have top-level bodies, and I've pointed out that LOCALLY should),
also it needs to clarify whether one top-level form is processed before
the next is read (can I do a DEFSTRUCT and then use that structure's
name in a #S in the next form?  seems reasonable to want to do that.).
However, it has a major problem of defining what lexical environment
things are in, and I don't think what you have now is right.  I'll
comment in detail later.

I'd like to point out that the defining characteristic of top-level is
not that the lexical environment is null, but that the lexical environment
does not contain any variables, functions, blocks, or go tags; it
contains only declarations, macros, and the COMPILE-FILE remote/local
environment business.  Also top-level is not nested inside any flow
of control (conditionals, iterations, catches [which are essentially
a kind of conditional]); that's why the compiler can treat defmacro,
for example, specially at top level, because it knows that the defmacro
will be executed exactly once at load time and in a fully known lexical
environment.

COMPILED-FUNCTION-REQUIREMENTS: this has some bad problems with closures,
and also needs to wait until EVAL-WHEN is settled.  More later.