#

## Issue &ENVIRONMENT-BINDING-ORDER Writeup

    Status: Proposal FIRST passed, Nov 89 X3J13

    Forum:		Cleanup
    Issue:		&ENVIRONMENT-BINDING-ORDER
    References:	CLtL p. 145-146, 63
                    Issue DEFMACRO-LAMBDA-LIST
    Category:	CLARIFICATION
    Edit History:   V1, 24 Oct 1989, Sandra Loosemore
    		V3, 02 Nov 1989, Sandra Loosemore (comments from Moon)

    Problem Description:

    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.

    Proposal (&ENVIRONMENT-BINDING-ORDER:FIRST):

    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.

      Rationale:

      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
      lists).

    Proposal (&ENVIRONMENT-BINDING-ORDER:LEFT-TO-RIGHT):

    Clarify that the all lambda variables in a DEFMACRO-style lambda list
    are bound left-to-right, including the &WHOLE and &ENVIRONMENT parameters.

      Rationale:

      This is more consistent with the order in which variables in ordinary
      lambda lists are bound.

    Current Practice:

    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.

    Benefits:

    The language specification is made more precise.

    Discussion:

    Moon says:
      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
      EXPLICITLY-VAGUE proposal.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.