issue DEFINING-MACROS-NON-TOP-LEVEL

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

Moon and I have exchanged some private mail on this issue that has
turned up something very troublesome.  It has to do with the part of
the proposal that says that macro functions created by DEFMACRO are
evaluated in the lexical environment in which the defining macro
appears, and Moon's suggestion that MACROLET macro functions also be
evaluated in a possibly non-null lexical environment.

The problem is that there isn't a convenient way for code-walkers (and
presumably compilers) to do this, even with our proposal for issue
SYNTACTIC-ENVIRONMENT-ACCESS.  Basically, you would have to do two
code walkers -- one to do a total macroexpansion on the body of macro
functions before coercing it to be a function, and another to do what
you really wanted the code walker to do in the first place.  What's
more, I'm confused about the correctness of simply evaluating the
fully-macroexpanded macro function with EVAL because of the
possibility of the environment containing SPECIAL or LEXICAL
declarations that wouldn't be picked up.

I don't think that going back to the CLtL position that all macro
functions are defined in a null lexical environment is consistent with
our current model of how defining macros work.  Our model says that
DEFMACRO's expansion should include something like
    (function (lambda ...))  
Ensuring that the macro gets defined in a null environment (even if
the DEFMACRO appears in a non-null environment) would mean it would
have to look something like
    (eval (quote (lambda ...)))
which I think we are all pretty much agreed is wrong.

I believe we really have two choices:

(1) Change our definition of top-level back so that top-level implies
    null lexical environment again, and have MACROLET continue to
    evaluate the macros in a null environment.  (The problem of early
    evaluation in a non-null environment would never arise then.)

(2) Require implementations to provide some primitive for causing
    evaluation in a non-null syntactic environment.  (This is required
    now internally anyway in order to support EVAL-WHEN COMPILE
    evaluation.)  One possibility is the ENCLOSE function that has
    been mentioned in connection with the cleanup issue COERCE-INCOMPLETE,
    that takes a lambda expression and a syntactic environment, and
    returns a function.  It would be an error for the lambda
    expression to try to refer to any of the variable or function
    bindings established in the environment.

Unless somebody can convince me that declarations don't really pose a
problem after all, I'm not sure if doing nothing (and requiring users
to do a lot of extra work to handle macro definitions) is a reasonable
alternative.  It certainly tends to defeat the purpose of 
SYNTACTIC-ENVIRONMENT-ACCESS, which was to make it easy to write a
correct code-walker.

Anybody have thoughts on this?

-Sandra
-------