Re: fixing our problems with setf

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

     Date: 20 Sep 87 19:03 PDT
     From: Gregor.pa@xerox.com
     Subject: fixing our problems with setf
     
     Unless we can get setf 'fixed' in the entire language, I propose that we
     solve our problems with setf by eliminating all the setf features from
     CLOS (except automatically generated writer methods).  That means get
     rid of the ability to say (setf <foo>) to defmethod, symbol-function,
     generic-function-labels, generic-flet and the others.
     
     My belief is that we are geting into trouble because we are confusing
     (generic) function naming with defining setf macros.  This gets us
     screwed because setf is a macro in yet another namespace and doesn't
     interact real well with our stuff.
     
     Put another way, there isn't (right now) anything called defun-setf.  If
     you want to do that you have to do (something like):
     
     (defsetf foo |setf FOO|)
     
     (defun |setf FOO| (x new-value) ...)
     
     
     Given that, I don't see whats so wrong with having to do:
     
     (defsetf bar |setf BAR|)
     
     (defmethod |setf BAR| ((x boat) new-value) ..)

The problem is that we can't always specialize on the new-value argument
using the short defsetf form.  The programmer will have to write a hocky
defsetf form to get around the problem of having optional arguments
(e.g.  implementing the setf form of SUBSEQ as a generic function).  We
lose the COMBINE-LAMBDA-LISTS abstraction.

I agree with Masinter, if we don't propose a fix, nobody will fix it.
Our haste of finishing the specs shouldn't make us adopt a short term
view when we know what the long term solution should be.

Patrick.