[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
standard-type-class or built-in-class
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
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.