#

## Issue MACRO-FUNCTION-ENVIRONMENT Writeup

    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:  Version 1, Pavel, March 21, 1988
    		   Version 2, Masinter,  8-Jun-88, (as per cleanup discussion)

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

Copyright 1996-2001, Xanalys Inc. All rights reserved.