[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on most recent draft: Chap 1 and 2
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 --