symbol-class is bad name

[Gregor.pa@Xerox.COM]

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

Gregor said:	

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

Moon said:

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?
-------