Cleanup Issue MACRO-FUNCTION-ENVIRONMENT

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

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 (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 given, or the argument is NIL, the null environment is used. 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)

(setf (macro-function 'bar env) ...) is an error.

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, and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0 does.

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

This issue was discussed starting in January 1987, but got tangled in a web of other related proposals. In its current form, the only objections have been that some other proposal or committee might otherwise change macro handling, or that this proposal doesn't fix enough of the problems.

Edit History