[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A (new) (old) definition of "top-level"
- To: Sandra J Loosemore <email@example.com>
- Subject: A (new) (old) definition of "top-level"
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 8 Mar 89 20:05 EST
- Cc: firstname.lastname@example.org
- In-reply-to: <8903080141.AA08237@defun.utah.edu>
Date: Tue, 7 Mar 89 18:41:35 MST
From: email@example.com (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
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
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.