[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CL types --> classes

    Date: Wed, 22 Apr 87 14:46 PDT
    From: Gregor.pa@Xerox.COM

My notes generally agree with your message.  Here are the differences
and extensions:

They say COMPILED-FUNCTION is in the same boat with FUNCTION.


    Class can change by setf of symbol-package.

There was an argument about whether Common Lisp allows setf of
symbol-package, but I think we came up with a way to use IMPORT to
change something that isn't a keyword into a keyword.  Traditionally
the type of an object is something you can't change.  Does the
existence of CHANGE-CLASS mean that KEYWORD should be a class?
I feel like leaving out KEYWORD on the basis that extra classes
shouldn't be put in if they aren't clearly useful, but this is an
issue that could go either way.


    ?? What is the reason for this ??

Subrange is scrawled next to these on my notes.  If these are
subranges then KEYWORD is too.


    CLtL only requires that these types be disjoint with each other.  We
    would like X3J13 to fix these too.

There are probably a lot of implementations in which one or more of these
is a subtype of ARRAY.  That might be hard to fix efficiently?

No list type-specifier names a class and no deftype names a class, say
my notes.


    I don't believe we excluded these but I believe Pavel
    said he would write up the rules about how these work.

The issue was that if there are methods defined for both
SHORT-FLOAT and SINGLE-FLOAT, but these types are collapsed into
one, the precedence order of the methods is not well-defined.
The only thing we thought of in the meeting was to signal an error
when this happens, but I suspect that would be unsatisfactory in

In the precedence relationships for built in classes with
multiple direct superclasses, I think we decided on

(defclass null (list symbol) ...)
(defclass vector (array sequence) ...)
(defclass list (cons sequence) ...)

Are we ready to write this up yet?