Comments on most recent draft: Chap 1 and 2

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

re:  . . . Two names are the same if they are eql.  The function symbol-class
     takes a name and returns the class associated with that name, or nil if 
     there is none.

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.

Also, isn't it true that SYMBOL-CLASS only takes a symbol, not a 
"generalized" name? (In the broader sense, a better name for this 
functionality might be FIND-CLASS).  At any rate, using a name like 
SYMBOL-CLASS, which implies parallels to SYMBOL-VALUE and SYMBOL-FUNCTION, 
and overgeneralizing it to whatever nomenclature scheme comes up seems 
like a real misdirection.

Incidentally, having *no* name for a class  (I'm not talking about symbols
as names) makes it hard to talk about a type specifier that refers to that
class.  Is is really so bad that anonymous classes can't be named in
type specifiers?  if they can't be named at all (i.e., "has no name")
then why should the conventions for type names be changed?  



-- JonL --