Status: Proposal FIRST passed, Nov 89 X3J13
References: CLtL p. 145-146, 63
Edit History: V1, 24 Oct 1989, Sandra Loosemore
V3, 02 Nov 1989, Sandra Loosemore (comments from Moon)
Issue DEFMACRO-LAMBDA-LIST states that &ENVIRONMENT can appear once
anywhere at top level of a macro lambda list, but doesn't say anything
about the order in which the &ENVIRONMENT variable is bound relative
to the other lambda-list variables.
Some implementations treat &ENVIRONMENT as a mechanism for naming the
second argument to the macro function, in which case it is bound
before any of the variables in the actual destructuring pattern.
Other implementations bind it with the other lambda parameters in the
usual left-to-right order.
The binding order of &WHOLE parameters is not an issue. This is
because a &WHOLE parameter must appear first in the lambda list, so
there is no difference between binding it first or binding it
left-to-right. The relative binding order of &WHOLE and &ENVIRONMENT
parameters is not an issue because neither one can include init forms
where the binding of the other might be visible.
There are two proposals, FIRST and LEFT-TO-RIGHT.
Clarify that the &ENVIRONMENT parameter is bound along with &WHOLE
before any of other variables in the lambda list, regardless of where
&ENVIRONMENT appears in the lambda list.
This proposal provides a convenient explanation for the special
treatment of &WHOLE and &ENVIRONMENT at top-level in a DEFMACRO-style
lambda list. Basically, these two parameters are stripped out and
used to name the two arguments to the macro function, then the binding
of the remaining arguments is handled exactly the same as at
non-top-level or in a DESTRUCTURING-BIND. It is also very
straightforward to implement this model (as opposed to having
special parsing code for destructuring top-level DEFMACRO lambda
Clarify that the all lambda variables in a DEFMACRO-style lambda list
are bound left-to-right, including the &WHOLE and &ENVIRONMENT parameters.
This is more consistent with the order in which variables in ordinary
lambda lists are bound.
Lucid CL, Utah CL, and KCL implement proposal FIRST. CMU CL
implements proposal LEFT-TO-RIGHT.
Symbolics Genera implements proposal FIRST. Specifically, &WHOLE is
bound first, followed by &ENVIRONMENT, then the destructuring
variables in the order listed.
Cost to implementors:
The changes are probably localized but potentially hairy. It is
possible that in some implementations it might be easier to completely
replace the code which handles lambda-list parsing and destructuring
than to try to patch it. Proposal FIRST is probably easier to
implement initially but the cost of converting an existing
implementation is probably about the same for both proposals.
Cost to users:
There are probably few user programs that would be affected by a
change in the binding order of &ENVIRONMENT parameters.
The language specification is made more precise.
I believe LEFT-TO-RIGHT is more clean, but I don't have strong feelings.
I am equally in favor of either of the two presented proposals or an