Re: Comments on most recent draft: Chap 1 and 2

[Danny Bobrow <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
for
(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?