subtypep?

[Jon L White <jonl@lucid.com>]

re: I was under the impression that you could define a CL type to be a
    subtype of another one, which would allow PCL to use the same
    mechanism, but I guess you can't do that.  Thanks for the info,

I know this may sound a bit pedagogical, but the type system of CL is 
just a "mathematical langauge" of __type specifiers__;  DEFTYPE does 
not provide any mechanism for new, structured data definitions. True, 
there are a few built-in mappings from type-specifiers to primitive
data objects -- CONS, INTEGER etc, -- but the *only* extension
mechanism in CL which allows new TYPE's to be assigned to new
categories of objects is DEFSTRUCT.  Since PCL choose to implement
objects of metaclass STANDARD-CLASS as little defstruct instances,
then an unmodified CL implementation must report them as such.

Actually, consider the alternatives in the portable subset of all
Common Lisp implementations.  Were standard-object's implemented as,
say, simple-vector's or cons's, then I'm sure you be much more 
unhappy with the resulting type confusions.

The X3J13 committee in fact had to add some additional requirements
of disjointedness for built-in types in Common Lisp -- primarily
so that classes could unambiguously be assigned for an interesting
subset of built-in types.  Remember: not all CL types have classes 
behind them; and as a mathematical language, there are infinitely 
many CL types which denote the same set of objects [Exercise: find 
three more type specifiers denoting the same set of objects as 
(UNSIGNED-BYTE 8).]

As a consequence of several X3J13 proposals, one may deduce that
the set of objects in any "standard" class must be disjoint from
the set of objects in any "structure" class; and this implies
that no type specifier can simultaneously refer to both of them
[because the intersection of two such classes is null.]  Although
you could construct a type (i.e., type specifier) that represents
the union of these two classes -- e.g.,
    (OR <some-structure-class> <some-standard-class>)
I don't believe that CLOS implementations will allow you to 
construct a class that is effectively the union of these two
classes.  The CLOS proposal X3J13/88-002R may not explicitly
forbid this situation, but implementations are typically
done in such a way that no "structure" class can have a
a "standard" class as a super-class, and vice-versa.  PCL
enforces this restriction by means of methods on the generic
function CHECK-SUPER-METACLASS-COMPATIBILITY.

A consequence of the above comments is that no portable program
(such as PCL) can hope to compensate completely for the 
deficiencies of the 1984 Common Lisp data typing system; that is 
why the proposed ANSI Common Lisp will be slightly different, and 
hopefully slightly better, than the 1984 version.  Although user's 
programs may postpone some of the difficulties by calling 
PCL:SUBTYPEP instead of LISP:SUBTYPEP, they will not be able (in 
a portable way) to fix up the internal calls that a particular CL 
implementaion may make to LISP:SUBTYPEP, and to other internal 
functions like it.
 

I apologize for this note dragging on for so long; but the topic 
is often filled with confusion or misinformation.  If I haven't 
been moderately clear in my comments above, then please contact me 
privately first, and perhaps we can "debug" a better explanation of 
the CL type system constraints before flooding the net with all
the intermediate comments.



-- JonL --