Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3

[Masinter.pa@Xerox.COM]

Gregor said in his ballot that comments would follow, but I can't find
them. Did I miss them? I saw some notes about a more general facility
for accessors and constructors of lexical environments on the CLOS
mailing list, so I hoped I was on the mark by adding that to the
discussion section.

Kent asked that NIL be explicitly allowed for the null lexical
environment. I put that in. 

Version 2 got lots of yes ballots.

Status: Ready for release?

!
Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   Version 1 9-Jan-87, Version 1 by Masinter (from Steele
list) 
                ...       7-Apr-87, merged with other environment
argument issues
                Version 2 29-May-87, by Masinter, extracted again 
                Version 3  5-Jun-87, by Masinter.
                
			
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. NIL can also be passed
explicitly to denote 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.

Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., 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.

A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.