Re: Issue: SETF-PLACES (version 1)

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

>     (b) phrases like "(FBOUNDP <function-specifier>)" should be changed
>         into "(FBOUNDP (UNDERLYING-NAME <function-specifier>))"; or
>         else other terminology should express the intent of what is to
>         be said.  For example, instead of saying: "When (FBOUNDP <f-s>) 
>         is  true ..." one could just as well say  "When <f-s> refers to 
>         a defined function ..."  The choice of which of these two formats 
>         to use is an editorial one.
>     (c) phrases like "(SYMBOL-FUNCTION function-specifier)" should be changed
>         into "(SYMBOL-FUNCTION (UNDERLYING-NAME <function-specifier>))";
>         or else other terminology should express the intent of what is to
>         be said.  For example, one might say "... the function referred 
>         to by <f-s>".  The choice of which of these two formats to use is
>         an editorial one.

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.

> Since the concept of a standard expansion for DEFMETHOD has been
> accepted, then it is clear that a form like 
>     (DEFMETHOD (SETF FOO) ...)
> will expand exactly the same as
>     (DEFMETHOD #.(UNDERLYING-NAME '(SETF FOO)) ...)
> The underlying call to ADD-METHOD will see the real function name used
> for the updator function.  The user-level interface of CLOS can still
> present the list format as acceptable; it is only the implementation of
> DEFMETHOD, DEFGENERIC, that will have to worry about converting to a
> "real" name.

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?

> Cost to Implementors:
> 
> Basically, none.  Implementations which already have Lisp Machine 
> style "function specs" can just define UNDERLYING-NAME and
> UNDERLYING-NAME-TO-SPEC as the identity function. 

If we don't have to also extend the meaning of FBOUNDP and
SYMBOL-FUNCTION.