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

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

This message is just about the environment of MACROLET issue.

    Date: Tue, 14 Mar 89 15:11:20 MST
    From: 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>
    >   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.

That's what I had in mind.  I believe the implementation of such error
checking is extremely simple (although I admit there might be
implementations that I don't know about where it would be difficult).
I'd most prefer that an error must be signalled, somewhat less prefer
that the consequences be unspecified, and least prefer that the
macro functions use a special lexical environment specifically defined
to be current in the macros and declarations, but null in the symbols,
functions, and blocks.

Upon reflection I think MACROLET would better be handled as a separate
issue.  Has this been discussed and assigned an issue name already?
The basic question is whether DEFMACRO macros and MACROLET macros should
be consistent in the lexical environment of their body, or whether
MACROLET macros should use the null lexical environment, unlike anything
else.  If there is not already anything for this, let me know and I
will write it up.  Let me know whether it should go to the compiler
committee or the cleanup committee.

    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.

I think this is a rather narrow attitude on compatibility.  What you
seem to have just said is that it's more important for the standard to
be compatible with whatever Lucid's current release does than for the
standard to be self-consistent; I doubt that even most people at Lucid
would agree with that.