standard type class

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

This is a first draft.

The problems with the term "standard type class" are:
 - the name is too close to "standard class" so it's easy to get confused.
 - the semantics are too ill-defined.  When we say "could be extended"
   to allow subclassing and make-instance, this sounds like it refers to
   standard type classes in general, but what it actually means is that
   an individual class documented as a standard type class could be
   implemented as a standard class.
 - we haven't made clear enough that an object has standard-type-class
   as -a- metaclass, but -the- metaclass is implementation-dependent

Suggestion:
 - eliminate the term "standard type class"
 - when we mean "a class that corresponds to a predefined Common
   Lisp type" we should say exactly that, no need to abbreviate.
 - rename the standard-type-class metaclass to built-in-class,
   and clarify that it is implementation-dependent whether any
   potentially built-in class is in fact built-in and has this
   metaclass.
 - clarify the requirements on portable programs

These are all the uses of the phrase "standard type class" (with or
without hyphens) that appear in the documentation as of a couple
days ago:

1-16 -- see rewrite below

1-34 -- see rewrite below

2-11 2nd remarks para -- delete the second sentence.  We don't need
a "for example" and don't need to say anything more than that change-class
is only guaranteed to work for standard classes.

2-22 1st remarks para -- delete the third sentence.  The section
"Redefining Classes" already covered the rules here.

2-54 last remarks para -- delete, this has already been covered and
doesn't need to be repeated.

2-79 1st args para last sentence -- this doesn't belong here, delete it.
Perhaps slot-value should say that it signals an error if given an
instance of a built-in class (I don't think it calls slot-missing
in that case.)


On page 1-16, the rest of the section after the first three paragraphs
is replaced by the following (edited from the TEX source on SAIL):

Many but not all of the predefined Common Lisp type specifiers have a
corresponding class with the same proper name as the type.  For example,
the type {\bf array} has a corresponding class named {\bf array}.  No
type specifier that is a list, such as {\tt (vector double-float 100)},
has a corresponding class.  No type defined by {\bf deftype} has a
corresponding class.

Each class that corresponds to a predefined Common Lisp type specifier
can be implemented in one of three ways, at the discretion of each
implementation.  It can be a {\bit standard class\/}, of the kind
defined by {\bf defclass}, a {\bit structure class\/}, defined
by {\bf defstruct}, or a {\bit built-in class\/}, implemented in
a special, non-extensible way.  For example, most Common Lisp
implementations reserve a particular bit pattern for representing
conses.  In such an implementation, {\bf cons} is a built-in class.

Built-in classes have restricted capabilities, because of their special
representation.  Attempting to use {\bf defclass} to add new subclasses
to a built-in class signals an error.  Calling {\bf make-instance} to
create an instance of a built-in class signals an error.  Many built-in
classes do not have slots and calling {\bf slot-value} signals an error.
Redefining a built-in class or using {\bf change-class} to change the
class of an instance to or from a built-in class signals an error.
However, built-in classes {\it can\/} be used as parameter specializers
in methods.

A portable program must assume that all classes that correspond to
predefined Common Lisp type specifiers are built-in classes.  In a
particular implementation one of these classes might be a standard
class, but in other implementations it could be a built-in class.
Thus a portable program may not define a subclass, make an instance,
reference a slot, redefine, or change-class a potentially built-in class.

It is possible to distinguish standard from built-in classes by checking
the metaclass.  A standard class is an instance of {\bf standard-class}
or of a subclass of it.  A built-in class is an instance of
{\bf built-in-class} or of a subclass of it.  Note that the metaclass
of a class that corresponds to a predefined Common Lisp type specifier
is implementation-dependent.

Each structure type created by {\bf defstruct} without using the
{\bf :type} option has a corresponding class.  This class is an
instance of {\bf structure-class}.  A portable program must assume
that {\bf structure-class} is a subclass of {\bf built-in-class}
and suffers the same restrictions.  Whether {\bf structure-class}
in fact is a subclass of {\bf built-in-class} is implementation-dependent.
The {\bf :include} option of {\bf defstruct} creates a direct subclass
of the class that corresponds to the included structure.

The purpose of specifying that many of the standard Common Lisp types
have a corresponding class is to allow users to write methods that
discriminate on these types.  
Method selection requires that a class precedence list can be
determined for each class.  This list orders the class and its superclasses
from most to least specific.

The hierarchical relationships among   
the Common Lisp types are maintained by the classes corresponding to  
those types.   Thus the existing type hierarchy is used for determining  
the class precedence lists for each class that corresponds to
a predefined Common Lisp type.
In some cases, {\it Common Lisp: The 
Language\/} does not specify a subtype/supertype relationship for two 
supertypes of a given type.   For example, {\bf null} is a subtype of
both {\bf symbol} and {\bf list}, but {\it Common Lisp: The Language\/} 
does not specify whether {\bf symbol} is more or less specific than {\bf
list}.  The \CLOS\ specification defines those relationships for all
such classes. 

The following table lists the set of classes that correspond to
predefined Common Lisp types required by
\CLOS.  The superclasses of each such class are presented in
order from most specific to most general, according to the class precedence
list for the class.

\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus .5 fil&&#\hfil\cr  %was &&#
\noalign{\vskip -9pt}
\hfil\bf Class&\bf Class Precedence List\span\omit\span\omit\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
array&t\cr
bit-vector&vector, array, sequence, t\cr
character&t\cr
complex&number, t\cr
cons&list, sequence, t\cr
float&number, t\cr
integer&rational, number, t\cr
list&sequence, t \cr
null&symbol, list, sequence, t\cr
number&t\cr
ratio&rational, number, t\cr
rational&number, t\cr
sequence&t\cr
string&vector, array, sequence, t\cr
symbol&t\cr
t\cr
vector&array, sequence, t\cr
\noalign{\vskip -9pt}
}}
\caption{}
\endfig

Individual implementations can allow other type specifiers to have a 
corresponding class.  Individual implementations can also add additional
subclass relationships and can add additional elements to the class
precedence lists in the above table,
as long as they do not violate the type
relationships and disjointness requirements
specified by {\it Common Lisp: The Language\/}.  
However, individual implementations are not free to add subclass
relationships involving user-defined standard classes.



This subsection on page 1-34 is replaced as follows:

\beginsubSection{Standard Metaclasses}

The \CLOS\ provides a number of predefined metaclasses.  These
include the following: {\bf standard-class}, 
{\bf built-in-class}, and {\bf structure-class}.
% funcallable-class?

\beginlist

\item{\bull}
The class {\bf standard-class} is the default class of classes defined
by {\bf defclass}.

\item{\bull} The class {\bf built-in-class} is the class of classes
that have special implementations with restricted capabilities.
All classes that correspond to the standard Common Lisp types
specified in {\it Common Lisp: The Language\/} by Guy L. Steele Jr.
are potentially instances of {\bf built-in-class} or a subclass
of {\bf built-in-class}.
%These types are listed in Figure~1-1.
It is implementation-dependent whether each of these classes
is actually built-in.

\item{\bull}
All classes defined by means of {\bf defstruct} are instances of 
{\bf structure-class} or a subclass of {\bf structure-class}.
The class {\bf structure-class} is potentially a subclass
of {\bf built-in-class}.

\endlist

\endsubSection%{Standard Metaclasses}