[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on most recent draft: Chap 1 and 2
- To: edsel!jonl@labrea.Stanford.EDU
- Subject: Re: Comments on most recent draft: Chap 1 and 2
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 3 Feb 88 18:22 PST
- Cc: Common-Lisp-Object-System@Sail.stanford.edu
- In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Wed, 3 Feb 88 14:37:51 PST
- Sender: Bobrow.pa@Xerox.COM
X3J13 may take on the task of extending the naming schemes
(such as "function specs', but possibly something else), so you
probably wouldn't want to specify something in CLOS that would be
at variance with that. In that light, I would say that
requiring EQL for the name-equivalence predicate is a bad idea;
EQUAL or something broader may be better. Best of all would be to
avoid any unnecessary entanglements in CLOS for now by just not
specifying what isn't really needed.
I would be happy with this. Would this take the form of not saying what happens
(symbol-class foo) and (setf (symbol-class foo) bar)
when foo is not a symbol. Should it say that:
"CLOS may be extended to cover situations in which foo is not a symbol."
Similarly for class-name. I would be happy to use the "extended" clause for
symbol-class, and simply not say anything about class-name.
But, haven't we already extended symbol-function to take lists of the form (setf
fn) as an argument. If not, how do we get hold of setf generic-functions?