[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fixing our problems with setf
Also because the expansion of setf does not depend on the argument
list of FOO or (SETF FOO), there can't be any problems with having to
re-expand (recompile) code after the defun for foo or (setf foo)
changes. This rule for setf always puts the new value argument as the
first of the other arguments, this rule always works since it doesn't
depend on the definition of FOO or (SETF FOO).
The point I see in favor of having the new value after all the required
is it suggests that it will be the least significant argument for method
selection. Putting new value first suggests that it will be the most
significant (which is generally not what you want). Besides this
point, the idea of having the combined setf lambda list independent of
the original lambda list is attractive.
The remaining issue is a scoping issue. We have introduced lexically
local setf functions, where before Common Lisp only had lexically global
setf macros. Thus the namespace of setf operators has been extended to
have a lexical component, just like the namespace of regular operators.
(Recall that "operator" means the union of functions, macros, and
special forms). Regular functions and setf functions naturally come in
pairs, but since they are defined separately we have to specify what
happens in various cases where only one is defined at a given lexical
Scoping is not a problem in my proposal provided the programmer never
uses defsetf. Because setf always expands the same way, all the
programmer needs to do is provide lexical definitions for the actual
setf function (SETF FOO).
I will be unrealistic to consider that programmers won't use DEFSETF.
All of what Moon included under this issue is still valid.