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

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

> Date: Tue, 14 Mar 89 15:58 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
>   The order in which
>   non-top-level subforms of a top-level form are processed by the
>   compiler is explicitly left unspecified.
> 
> I can't figure out what this means and the example in the rationale
> section that purports to explain this does not shed any light, since in
> the example there is no change of order of evaluation.

I don't know how to explain this any more clearly -- what's in the
current version of the proposal is about the third attempt I've made.
Well, here goes a fourth attempt.

Suppose I have a top-level DEFMACRO at the top of the file.  Item (3)
guarantees that this DEFMACRO will be processed before any top-level
forms that appear textually after it.  That means I can refer to the
DEFMACRO in those subsequent forms and guarantee that the compiler has
already "seen" the macro definition.  The same rule applies to any
other defining macros that do compile-time magic at top-level.

Now suppose expanding this macro has some side-effects, such as
SETQ'ing a special variable.  If I have two calls to the macro at
top-level, I can reliably depend on the side-effects happening in the
same order that the calls appear textually.  But, the other thing that
item (3) says is that if the two macro calls are embedded at
non-top-level, I can't rely on the order in which the compiler will
expand them.

The example shown in the rationale explains why.  Both code fragments
are semantically identical -- as you observe, there is no change in
the order of evaluation.  However, the *textual* order of subforms has
changed.  If we wanted to guarantee that compiler processing of 
*always* happens in the same order that they appear textually,
implementations would be prohibited from doing this kind of
transformation.  That's why item (3) makes an exception for embedded
non-top-level forms.

I agree this could be made into a separate issue and be expanded to
include a statement that processing of top-level forms is interleaved
with reading.  It had more to do with this issue when the definition
of top-level appeared here.

>   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 form is
>   evaluated.
> 
> I strongly believe that MACROLET must be consistent with this, which
> would be a change.  Has that been dealt with as a separate issue?  If
> not, it should either be added to this issue or brought up as a
> separate issue, with the interdependency noted in both writeups to
> minimize the chance of an inconsistent vote.

The problem with MACROLET is that it defines the macro functions at
compile time even if it appears at non-top-level, while all the other
ones listed only do so at top-level.  Non-top-level environments are
not guaranteed to be "complete" at compile time; bindings of functions
and variables don't exist yet.  I suppose we could say that trying to
refer to those functions and variables in the macro functions is an
error of some variety.

In any case, this would be a somewhat more incompatible change than
what the proposal currently says.  Lucid, for example, evaluates
DEFMACRO macro functions in the lexical environment that the DEFMACRO
appears (in spite of what CLtL says), but always evaluates MACROLET
macro functions in a null lexical environment.

-Sandra
-------