standard-type-class or built-in-class

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

    Date: 22 Oct 87 16:07 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

    I think the concept of standard-type-class was one we had eliminated.  I
    think a potentially better way to describe these this mapping is:

    "The classes corresponding to predefined Common Lisp data types can be
    one of two types.  There are those that are implemented specially in the
    implementation, and these have metaclass built-in-class.  For these
    built-in classes, an error is signalled if a user tries to create an
    instance of such a class using make-instance.  An example of such a
    class is integer.  

Add "in almost all implementations"; we can never guarantee that any class
is built-in in all implementations.

		       Some classes corresponding to predefined Common Lisp
    data types may be implemented as instances of the standard metaclass.
    For example, ratio or rational might be such classes (or stream if that
    gets included).  For these, instances can be made using make-instance.
    It is implementation dependent which of the Common Lisp data type
    classes are implemented in each way."  

    I suggest that where ever the expression "standard type class" is now
    used, we use either built-in-class if we are referring to implementation
    issues, and "Common Lisp data type classes" when we are referring to the
    mapping.

I remember we discussed this, but I don't have any record of a decision
having been made.  I like your suggestion here and favor adopting it,
even at this late date.  I think the key thing you are suggesting is that
the CLOS standard admits that the meta-class of some objects is
implementation-dependent, but having granted that, is free to be more
specific about how the meta-class controls the behavior.

We'd want to add "No portable program can depend on whether a Common Lisp
data type class is a built-in-class or a standard-class" (this phrase
is essentially lifted from the Error Terminology section).

    Question:  Will we allow specialization of built-in-classes.  An example
    of the use of this is having a general Newton-Rafson iteration method on
    number, and allowing a new specialization of number that could inherit
    such a method.

If a subclass of a built-in-class is a built-in-class, we cannot allow it,
since by definition only the implementor can create new built-in-classes.
Perhaps you're asking whether a standard-class can be a subclass of a
built-in-class; this is asking for trouble, because some methods on
the built-in-class are likely to depend on instances' implementation-specific
structure, and although they would be applicable to the subclass, they
would not work.  I think we want to carry the current prohibition on
subclassing of standard-type-classes over to built-in-classes.

You could also be asking whether we should say that number is so general
a class that it would never be built-in to an implementation, so we will
say that number is a standard-class, even though some of its subclasses
may be built-in-classes.  This bothers me too, because CLtL contains
"generic" functions such as + that are defined to work on all subtypes
of number, and if we allow adding new subtypes of number, then we have
to add a way to define methods for +, which is something that we made
an explicit non-goal back at the beginning of this effort.