[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: SETF-PLACES (version 1)
- To: Jon L White <firstname.lastname@example.org>
- Subject: Re: Issue: SETF-PLACES (version 1)
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Tue, 22 Nov 88 18:38:59 CST
- Cc: email@example.com
- In-reply-to: Msg of Tue, 15 Nov 88 14:56:59 PST from Jon L White <firstname.lastname@example.org>
- Sender: GRAY@Kelvin.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