Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 5

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

> Date: Wed, 21 Dec 88 20:40:59 PST
> From: Jon L White <jonl@lucid.com>
> 
> I'm not at all comfortable tying in the definition of "toplevel" to READ.  
> In particular, lots of so-called top-level forms are not explicitly read 
> in, but rather are constructed up by macros which return something like 
> 
>     `(PROGN (DEFUN ...) (DEFMACRO ...) ...<whatever>...)

The definition in the proposal is intended to cover this case; it does say
that the expansion of a top-level macro is also considered to be top-level.
Perhaps I can word this section better.  How about:

- A form read by COMPILE-FILE from the input file is a top-level form.

- Forms within the body of a top-level PROGN or EVAL-WHEN are also 
  top-level forms.

- The expansion of a top-level macro call is also a top-level form.

To me, this kind of recursive definition seems much simpler than
saying "null lexical environment" and then listing a zillion
exceptions.  Top-level implies null lexical environment, but the
reverse is not true. 

> re: Specify that top-level forms in a file being
>     compiled are guaranteed to be processed sequentially, but the order in
>     which subforms of a top-level form are processed by the compiler is
>     explicitly left unspecified.
> 
> I don't understand the motivation for saying anything at all about the
> order of processing the subforms; in particular, it conflicts with a
> perceived requirement  that if (PROGN (A) (B)) is at toplevel, then (A) 
> and (B) must be processed " at toplevel" and **in order**.

Oops, I guess I lost the rationale for this when I revised the
proposal.  It's to allow compilers to perform certain kinds of
source-to-source transformations that may reorder subforms.  In any
case, I think it's reasonable to specify that the bodies of top-level
PROGNs and EVAL-WHENs are processed in order, and the proposal should be
more explicit about that.

-Sandra
-------