[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: SETF-PLACES (version 1)
- To: Gray@DSG.csc.ti.com
- Subject: Issue: SETF-PLACES (version 1)
- From: Jon L White <firstname.lastname@example.org>
- Date: Mon, 28 Nov 88 22:44:19 PST
- Cc: email@example.com
- In-reply-to: David N Gray's message of Tue, 22 Nov 88 18:38:59 CST <2805237539-1438981@Kelvin>
re: There is a non-editorial issue here: are FBOUNDP and SYMBOL-FUNCTION
required to accept anything returned by UNDERLYING-NAME, or are they
only meaningful for symbols? On Lisp Machines these are primitives for
accessing symbol definition cells while other functions, FDEFINEDP and
FDEFINITION, accept any function spec.
Yes, the current CLOS spec requires FBOUNDP and SYMBOL-FUNCTION to
accept "function specs"; see for example the documentation in 88-002R
of ENSURE-GENERIC-FUNCTION. This proposal (SETF-PLACES, or whatever
name you want to call it) does not purport to change that requirement
for those implementations that already have "function specs" implemented.
[Incidentally, the earlier SETF-FUNCTION-VS-MACRO proposal failed to
address the SYMBOL-FUNCTION issue.]
re: For consistency, shouldn't this be accepted by all function-defining
macros and special forms? Besides DEFMETHOD and DEFGENERIC, there are
DEFUN, FLET, LABELS, GENERIC-FLET, GENERIC-LABELS, WITH-ADDED-METHODS,
and DEFCLASS. I also can't find any mention of the special form
FUNCTION in the proposal; shouldn't it also accept function specifiers?
Most certainly not! This is the whole point of this proposal -- to
limit non-symbol names to precisely the one place in CLOS where it is
extremely difficult to use just one symbol, namely in the SETF generic
methods. Note that DEFMETHOD, DEFGENERIC etc doesn't define "a function",
but rather a piece of one.
The whole reason that anyone outside the Brothers-of-MIT-LispMachine
community acceed to compound names for setf methods is that it was very
difficult to use a single symbol for specifying what "piece" of what
"function" is meant. Further, by Gregor's argumentation, the non-symbol
name need only appear in the outer CLOS syntax, since DEFMETHOD is just
a macro which will expand out into something more primitive (which in
many implementations will be a hoked-up symbol a la the example code.)
Similarly, requiring a few functional entries of CLOS to accommodate a
limited function spec notion is nowhere near the burden on other
implementations that extending to full functions specs would be.
Looking ahead, I see that several more of the "Brothers-..." have
made the same request, which basically boils down to requiring all
implementations to have the essence of function specs by "trojan horse".
Contrary to what has been said, the X3J13 group is not adamantly against
SETF-FUNCTIONS -- rather, they are balking at the notion of lists as
function names. I fervently hope that in the future some improved
version of function specs -- definition specs -- will be accepted into
Common Lisp; but in my opinion, the consensus to do it now just isn't
there. It just does no good to pretend that this one itsy-bitsy,
teensy-weensy extension isn't full functions specs; the issues seen
so clearly by many are:
(1) once you've had to dicker around with all the places in an
implementation to make (SETF <foo>) uniformly acceptable as
a function name, you have basically done all the necessary
work for "functions specs". So if it walks like a duck,
quacks like a duck . . .
(2) functions specs [and indeed "definition specs"] break a very
fundamental notion people have about function names -- that
only symbols will do; it will take some longer period of time
to get them used to the newer ideas.
-- JonL --