A (new) (old) definition of "top-level"

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

    Date: Tue, 7 Mar 89 18:41:35 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I've spent the past few hours digging around through the literature to
    try to get a historical perspective on the use of the term
    "top-level".  Believe it or not, I've actually found a definition of
    the term, from the 1st edition of Winston & Horn's LISP book:

      A function is said to be defined or used in the top-level environment
      if its definition or use is directly demanded by a user, rather
      than indirectly by way of the evaluation of one or more other functions.

I think this is an unrelated use of the same word and doesn't tell
us anything.

    Now to to extend this to file compilation.  LOADing a source file is
    defined as reading and evaluating forms from the file.  Since there is
    direct evaluation going on, each form that is read from the file is
    top-level.  This notion applies just as well to COMPILE-FILE, which
    must arrange for the loader to "evaluate" or "execute" each of the
    top-level forms. 

    Finally, we have implicitly accepted the idea that macroexpansion by
    the compiler must preserve semantics.  That implies that
    macroexpansion should not have any effect on top-level-ness.  Thinking
    about our simple compiler model that doesn't do much besides walk the
    code to expand all macros and print out the results, if it is allowed
    to turn the bodies of COMPILER-LETs, MACROLETs, and SYMBOL-MACROLETs
    into PROGNs, then that would be an argument for saying that those
    three special forms should be treated the same as PROGN as far as
    top-level-ness goes.  However, that rationale wouldn't cover
    constructs like LOCALLY and LABELS (as Moon suggests) unless we modify
    our compiler model. 

    This way of thinking about top-level-ness makes sense to me.  How
    about the rest of you?

I think this makes sense, but all it says is that a top-level form is
one that is not inside another form.  

We need to go back and ask why the compiler has to have a concept of
top-level form in the first place.  (Surely it would be better if we
could just jettison the concept entirely.)  I think the concept exists
only because in compile-file defmacro as a top-level form does something
rather different from defmacro as a non-top-level form.  There are a few
others (deftype, defsetf) in the same category.  Then the important
thing about top-level forms is not whether they are enclosed in
parentheses, but whether they can get this special compiler treatment of
defmacro.  I could now repeat what I said yesterday but I'll spare you.
I think it fits very well with your simple compiler model, though.