Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: SETF methods
Message-ID: <32895@think.UUCP>
Date: 5 Dec 88 17:24:52 GMT
References: <613@cnetlu.UUCP> <3761@pt.cs.cmu.edu>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 42

In article <3761@pt.cs.cmu.edu> ccm@a.gp.cs.cmu.edu (Christopher McConnell) writes:
>The CLOS spec is specifying how to define setf methods (as in CLOS
>methods with specializers) not the normal CL setf methods.  So, you
>have to say (defmethod (setf woof) (value (object blah))).  You use
>define-setf-method to define normal setf methods.

No, that's not the answer.  The calling sequence for such a method
would be

	(setf <woof> <value> <blah>)

and that is not the normal SETF syntax.  CLOS needs a way for a class
to customize the behavior of

	(setf (<slot-name> <object>) <value>)

This is done by defining a method whose NAME is (setf <slot>), e.g.

	(defmethod (setf woof-frob) ((object woof) value)
	  "Set the FROB slot of a WOOF."
	  ...)

For this to fit in well with the rest of the system, general support
must be made for functions with names of the form (SETF <symbol>).
For instance, after doing the above DEFMETHOD, (function (setf
woof-frob)) should be valid.  Such general support has been proposed
within the ANSI committee (it has been bogged down for a while, mostly
because of a controversy over whether this is really needed, and if
so, whether SETF should be a special case or we should have a general,
extendable "function spec" facility (as several Lisp systems do)).

There are a couple of reasons why DEFINE-SETF-METHOD isn't good enough
for this feature.  The main problem is that we need names for these
functions, not just a way to define them and get them.  For example,
GENERIC-FLET and GENERIC-LABELS also need to be able to bind these
names.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar