"Written Responses" to CLOS 88-002: SYMBOL-CLASS is poorly named

[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 
(or removed!):
    symbol-class
    cboundp
    cmakunbound
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.]


Benefits:

  (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.
    


-- JonL --