Issue: MACRO-FUNCTION-ENVIRONMENT

[Pavel.pa@Xerox.COM]

Issue:         MACRO-FUNCTION-ENVIRONMENT

References:    MACRO-FUNCTION, p. 144
               MACROLET, pp. 113-4
               &ENVIRONMENT, pp. 145-6
               MACROEXPAND and MACROEXPAND-1, pp. 151-2

Category:      ADDITION

Edit history:  Pavel, March 21, 1988 (Version 1)

Problem description:

The &ENVIRONMENT argument to a macro-expansion function may only be used as the
second argument to the functions MACROEXPAND and MACROEXPAND-1.  It is sometimes
more convenient, however, to be able to work directly with the more primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably
based.  However, since MACRO-FUNCTION does not take an environment argument, it
cannot be used in situations in which that environment must be taken into
account.

Proposal (MACRO-FUNCTION-ENVIRONMENT:YES): Add an optional second argument to
MACRO-FUNCTION, that argument being an environment that was passed as the
&ENVIRONMENT argument to some macro expansion function.  If the argument is not
passed, then it defaults to the null environment.  MACRO-FUNCTION will now
consider macro definitions from that environment in preference to ones in the
global environment.  It is an error to supply the environment argument in a use
of MACRO-FUNCTION as a SETF location specifier.

Examples:

(macrolet ((foo (&environment env)
              (if (macro-function 'bar env)
                 ''yes
                 ''no)))
   (list (foo)
         (macrolet ((bar () :beep))
            (foo))))

=> (no yes)

Rationale:

Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one.  By changing this
state of affairs, the model of macro expansion becomes somewhat simpler.  Also,
more flexible use of the facility is enabled.

Current practice:

Xerox Common Lisp already implements this proposal.  Symbolics Common Lisp,
Lucid/Sun Common Lisp and Kyoto Common Lisp do not.

Cost to Implementors:

This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.

Cost to Users:

The change is upward-compatible and so poses no cost to users.

Cost of non-adoption:

One more (small) semantic wart on the language.

Benefits:

The function that users think of as being more primitive really is.

Aesthetics:

This slightly cleans up the language.

Discussion:

Pavel is strongly in favor of the proposal.