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

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

Here's a revised proposal on this issue for your entertainment.

Issue:		DEFINING-MACROS-NON-TOP-LEVEL
References:	CLtL p. 66-70, 143
		Issue EVAL-WHEN-NON-TOP-LEVEL
		Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		Issue COMPILER-LET-CONFUSION
Category:	CLARIFICATION, ENHANCEMENT
Edit History:   6-May-88, V1 by Sandra Loosemore
		9-Jun-88, V2 by Sandra Loosemore
		12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
                21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
		16-Dec-88, V5 by Sandra Loosemore (major restructuring)


Problem Description:

CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.

On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context.  Compilers, for example, may not recognize these forms
properly in other than top-level contexts".  At least one implementation 
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.


Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW

(1) Remove the language from p. 66 of CLtL quoted above.  Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations.  However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.

(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment.  Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining macro is
executed.

(3) Clarify that ``top-level forms'' are evaluable data objects read
in from an input source (such as a keyboard or disk file) by
successive calls to the function READ; these forms would be evaluated
by the interpreter in a null lexical environment.  As special cases,
forms within a top-level PROGN, EVAL-WHEN, or COMPILER-LET are also
considered to be top-level forms, as is the expansion of a macro call
appearing at top-level.  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.


Rationale:

The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').  

There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there.  However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether. 


Current Practice:

CLtL mentions only that forms within a top-level PROGN, and not 
COMPILER-LET, are treated as top-level.  However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).


Cost to implementors:

Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.


Cost to users:

None.  This is a compatible extension.


Benefits:

The notion of defining macros as being somehow special when they
appear at top-level is removed.  Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.


Discussion:

This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE.  In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
-------