[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
symbol-class is bad name
One of the comments we received complained that symbol-class was poorly
named. It went on to suggest that cboundp and cmakunbound should be
removed from the language.
The full text of the comment was:
Date: Tue, 26 Apr 88 21:25:20 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
SYMBOL-CLASS is poorly named
The close binding of classes to symbols as names is a poor choice; there
really is no analogy with the other CL constructs that are currently
closely bound in with symbols (i.e., the ones that have "slots" in
the symbol reserved for them). Thus the following functions should renamed
A reasonable renaming for 'symbol-class' is 'class-named'; a reasonable
replacement for 'cboundp' is simply whether or not 'class-named' returns
non-nil; a reasonable replacement for 'cmakunbound' is simply
(setf (class-named <foo>) nil)
Current CL "slot" names for symbols are in fact defensible. Generally,
there are two grounds:
(1) every symbol has a SYMBOL-NAME component, and virtually every
symbol has a SYMBOL-PACKAGE component; thus for storage efficiency,
having a slot in the symbol structure is best.
(2) many symbols have either a symbol-function or symbol-value
component; but more importantly, these properties implement two
of the basic features of the Lisp programming lanugage syntax --
function-call to dynamically-linked functions and free-variable
access to dynamic bindings; thus for running-speed considerations,
these should be a "slot" (i.e., the access from a symbol to its
global function or its dynamic value must be very fast).
(*) SYMBOL-PLIST is the weakest case of the existing slots; probably
no one would grieve if it were not implemented as a slot (but rather
as, say, a hashtable lookup).
Some persons have pointed out that CLtL does not require actual "slots" --
and that a deep-bound implementation of Common Lisp would not, for example,
implement SYMBOL-VALUE as a slot access. But this is a red-herring, since
even in deep-bound implementations there is the need for "global value"
slot for exactly the same reasons. Furthermore, nearly every commercial
implementation does indeed implement these particular symbol properties
as "slots"; one must assume that these vendors have reasonable grounds
for doing so, such as the above-mentioned ones.
However, there is no need for a "slot" for classes. Rather, the tendency
now is to prepare for names which are not symbols -- i.e., the "Definition
Specs" proposal before X3J13 [but since only symbols can name functions
in program syntax, there still is no need for name-to-function mapping to
be fast except on symbols]. It makes perfectly good sense to be able to
name classes with non-symbol "definition specs", although I wouldn't suggest
that these non-symbol "specs" be permissible as parameter-specializer-names;
at worst this would limit such names to classes that are "built up" with
primitives lower than DEFMETHOD etc.
Instead of the paradigm SYMBOL-<foo>, there is similar use of the paradigm
<foo>-NAMED elsewhere. In Gregor's slides before the recent X3J13 meeting,
he actually used CLASS-NAMED in a place or two, proving that that is the
more "natural" name for this feature. In a preprint of the paper "An
Object-Oriented Database System to Support an Integrated Programming
Environment", by Dan Weinreb et. al. of Symbolics, the authors describe
a database system linked closely with CLOS. "Entities" in this database
scheme have a name (always a symbol); the example entities which have a NAME
slot all have an "inverse" name mapping function called "<foo>-NAMED". The
PERSON entity has a NAME slot -- presumably to be accessed as PERSON-NAME;
and it also has, explicitly, the inverse PERSON-NAMED. Similarly for
DEPARTMENT-NAME and DEPARTMENT-NAMED. This is independent evidence of a
widespread convention: for a category of named things <foo>, the
name-to-thing mapping should be called <foo>-NAMED.
One possible objection: a named object with components will frequently have
names assigned to the components by suffixing "-<component-name>" to the
object name. Thus CLASS-NAMED might be mistaken for the NAMED slot of
classes. I claim it will never be so mistaken, primarily because of the
wide-spread use of the protocol just described, and also because there is a
tendency *not* to give names to components that are parsable (in English) as
a word in the past tense. Thus NAME and FROB are good component names for
classes, but NAMED and FROBBED are not. It just doesn't happen. If someone
wanted, say, a REDEFINED slot, as a way of remembering whether or not the
class had ever been redefined, he _probably_ would call it REDEFINED-P.
Note also that in the database paper just cited, there is an entity
COURSE with a TITLE slot; and the inverse name mapping is, very
appropriately, called COURSES-ENTITLED -- the "past tense" protocol.
[I might even suggest this simple linguistic device is worth noting
somewhere as a "good style" note.]
(1) refrain from making the mistake of suggesting that symbols have
a "class" slot; reduce false cognates on names like SYMBOL-PACKAGE.
(2) remove artificial blocks to the use of non-symbol names.
(3) align with the common protocol of using "<foo>-named" as the mapping
from names to <foo>'s.
We already explained that we felt that it was more conventional with
CLtL to use symbol-class. Jonl's arguments here don't change my mind
about that. I think non symbol names are a horrible idea. It is a
major step away from a lisp-1. FIND-CLASS might not be a bad name
The idea that naming a function SYMBOL-xxx implies that every symbol
necessarily has associated with it 32 bits of storage to hold an xxx is
simply ludicrous. So is the idea that language design should be
dictated by typos in Gregor's slides. There is no mumble-NAMED
convention in Common Lisp, and we felt it would be doing the language
a disservice to introduce a new convention instead of using one of
the existing ones. FIND-CLASS would be okay with me; in Flavors it's
(FLAVOR:FIND-FLAVOR name &optional (error-p t) (environment nil)).
What do others think?