[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fixing our problems with setf
- To: Gregor.pa@XEROX.COM
- Subject: Re: fixing our problems with setf
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Tue, 22 Sep 87 09:36:10 CDT
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Msg of 20 Sep 87 19:03 PDT from Gregor.firstname.lastname@example.org
Date: 20 Sep 87 19:03 PDT
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.