[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SETF-FUNCTION-VS-MACRO (Version 1)
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: SETF-FUNCTION-VS-MACRO (Version 1)
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Thu, 15 Oct 1987 20:21 EDT
- Cc: CL-Cleanup@SAIL.STANFORD.EDU
- In-reply-to: Msg of 15 Oct 1987 17:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
- Sender: FAHLMAN@C.CS.CMU.EDU
I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO). This seems like a more radical change than is really necessary to
accomplish the stated purposes. It is a considerable extension to the
idea of a "function name", at least for standard Common Lisp
implementations that do not implement Lisp machine style function-specs.
Would it not be simpler to introduce a new setf-able access function
GET-SETF-FUNCTION which takes a symbol and returns the associated SETF
function? Under Moon's proposal a SETF form expands into something like
(funcall #'(setf foo) ...). This would become (funcall
(get-setf-function foo)...). I assume that in either case one must use
an explicit funcall and not just drop this "name" into the car-position
of an expression to be evaluated.
The one problem I can see with this alternative proposal is that it
there is no very good way to do something like FLET for the setf
function if there is not a name-like entity that can be bound. Is that
the reason for introducing this new kind of "name" instead of just
setting up the association with a setf-able function? Of course, we
could arbitrarily add some tweak to FLET that would locally rebind the
setf-function, but maybe Moon's scheme is more regular after all.
If we do go ahead with Moon's proposal in its current form, it would be
a good idea to address this concern and why something like the
alternative discussed here is not a better choice.
I assume that this would not preclude the addition of something like the
function specs that are present on the Lisp machine? If we finally
decide that Common Lisp is going to remain a Lisp-2, then we might want
to look at that whole issue again.