Re: fixing our problems with setf

[Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>]

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

Patrick.