Re: Issue: SETF-PLACES (version 1)

[David N Gray <Gray@DSG.csc.ti.com>]

> Yes, the current CLOS spec requires FBOUNDP and SYMBOL-FUNCTION to
> accept "function specs";
...
> re: For consistency, shouldn't this be accepted by all function-defining
>     macros and special forms? 
...
> 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.  

But if you are going extend the lowest level primitives, FBOUNDP and
SYMBOL-FUNCTION, to accept function specs, then I don't see that you
gain very much by saying that higher-level macros and special forms
won't accept them.  DEFUN would typically be implemented as a macro that
expands into (SETF (SYMBOL-FUNCTION ...) ...), so if SYMBOL-FUNCTION
accepts function specs, wouldn't DEFUN also accept them automatically?

If the intent is to limit the amount of change to implementations that
don't already support function specs, it seems like it would be easier
to leave FBOUNDP and SYMBOL-FUNCTION alone, introduce FDEFINEDP and
FDEFINITION, and then say that DEFMETHOD, DEFGENERIC, etc. use
FDEFINITION instead of SYMBOL-FUNCTION.  A portable definition using
your conversion function is:

  (DEFUN FDEFINITION (FUNCTION-SPEC)
    (SYMBOL-FUNCTION (UNDERLYING-NAME FUNCTION-SPEC)))
  (DEFUN FDEFINEDP (FUNCTION-SPEC)
    (FBOUNDP (UNDERLYING-NAME FUNCTION-SPEC)))
  (DEFSETF FDEFINITION (FUNCTION-SPEC) (DEFINITION)
    `(SETF (SYMBOL-FUNCTION (UNDERLYING-NAME ,FUNCTION-SPEC))
           ,DEFINITION))

This approach also minimizes changes for those of use who do already
support function specs.  The next question is whether there is really a
need for the user to know about UNDERLYING-NAME.  The only use I can
think of would be to do a GET on the underlying symbol, or to use it as
a key in an EQ hash table, but neither of those would be portable since
UNDERLYING-NAME could return a non-symbol on some implementations.  We
could instead introduce a portable interface to associating properties
with function-specs:

  (DEFUN FUNCTION-SPEC-GET (FUNCTION-SPEC PROPERTY &OPTIONAL DEFAULT)
    (GET (UNDERLYING-NAME FUNCTION-SPEC) PROPERTY DEFAULT))
  (DEFSETF FUNCTION-SPEC-GET (FUNCTION-SPEC PROPERTY &OPTIONAL DEFAULT) (VALUE)
    `(SETF (GET (UNDERLYING-NAME ,FUNCTION-SPEC) ,PROPERTY) ,VALUE))

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

But I've just shown you how to implement the essence of function specs
in only eleven lines of code.  Well, make that thirteen because you
probably want this too:

  (DEFUN FUNDEFINE (FUNCTION-SPEC) 
    (FMAKUNBOUND (UNDERLYING-NAME FUNCTION-SPEC)))

But that's it; it's not really that big a deal.  There is still a
separate question of where you want FDEFINITION etc. to be used instead
of SYMBOL-FUNCTION etc.  Mightn't it be easier to change them all
consistently than to have to document which forms of function names can
be used where?

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

But if you accept lists to name functions in certain contexts, how does
it really help to say that they aren't "function specs"?  Since I'm
obviously coming from a very biased perspective, I don't see anything
un-esthetic about using lists as function names.  It's certainly a
concept that has been around a long time and has proven very useful.