Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1

[Masinter.pa@Xerox.COM]

Status:  ready for release? [Use ballot]      

Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   9-Jan-87, Version 1 by Masinter (from Steele list) 
                7-Apr-87, merged with other environment argument issues
                29-May-87, Version 2 by Masinter, extracted again 
			
Problem Description:

If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,

(defmacro special-incf ... (get-setf-method ...) ...)

then  

(macrolet ((test (x) `(car ,x)))
	(special-incf (test z)))

would not "see" the test definition.

Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. 

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

The language specification should be explicit on the point that
MACROLET, FLET and LABELS can shadow a SETF method; a SETF method
applies only when the global function binding of the name is lexically
visible.

Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although
some do not.

Adoption Cost:

Some implementations will have to add this feature, although it is not a
major change.

Benefits:

This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.

Conversion Cost:

This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct. 

Discussion:

The cleanup committee supports this change.