GET-SETF-METHOD-ENVIRONMENTSETF 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.
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, within the scope of a MACROLET, FLET and LABELS, global SETF definitions of the name defined by the MACROLET, FLET or LABELS do not apply. A SETF method applies only when the global function binding of the name is lexically visible. All of the built in macros of Common Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location specifications obey this convention.
;;; This macro is like POP
(defmacro xpop (place &environment env) (multiple-value-bind (dummies vals new setter getter) (get-setf-method place env) `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter)) (prog1 (car ,(car new)) (setq ,(car new) (cdr ,(car new))) ,setter)))))
(defsetf frob (x) (value) `(setf (car ,x) ,value))
;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
(xpop (frob z)))
;;; The following is an error; an error may be signaled at macro expansion time
(flet ((frob (x) (cdr x)) (xpop (frob z)))
GET-SETF-METHOD to take an optional argument which is incompatible with this use.SETF'd forms might start working differently if the internal implementation of SETF is changed. The likelihood of this affecting a user's program is very small.MACROLET, FLET and LABELS in portable code which might also have SETF forms.SETF methods cannot work correctly within lexically defined function symbols without this change. This change makes the language more consistent and correct.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.