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

[Jon L White <jonl@lucid.com>]

re:  Clarify that all defining macros which create functional objects 
    (including DEFMACRO, ...) must ensure that those functions are
    defined in the lexical environment in which the defining macro is
    executed.
Wouldn't this read more smoothly if it said "in which the defining
form is evaluated"?


re: (3) Clarify that ``top-level forms'' are evaluable data objects read
    in from an input source (such as a keyboard or disk file) by ...

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>...)

I liked Walter's suggestion that "toplevel" be made synonymous with
"null lexical environment".  Of course, the difficulty there is that
one must specify that the call to (BAR) in each example below is
not in a null environment:
    (FOO (BAR))                       ;where FOO is an ordinary function
    (<special-form>  ... (BAR) ...) 
where <special-form> is any listed on CLtL page 57 except PROGN,  QUOTE,
THE, and EVAL-WHEN.  For the exceptions, (BAR) is "at toplevel" iff
the wrapping form is "at toplevel".


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**.


-- JonL --