Issue: SETF-PLACES (version 1)

[Jon L White <jonl@lucid.com>]

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 --