The Common Lisp data type hierarchy is tangled and purposely left somewhat
open-ended so that implementors may experiment with new data types as
extensions to the language. This section explicitly states all the defined
relationships between types, including subtype/supertype relationships,
disjointness, and exhaustive partitioning. The user of Common Lisp should not
depend on any relationships not explicitly stated here. For example, it is not valid
to assume that because a number is not complex and not rational that it must be
a float, because implementations are permitted to provide yet other kinds of
numbers.
First we need some terminology. If x is a supertype of y, then any object of
type y is also of type x, and y is said to be a subtype of x. If types x and y are
disjoint, then no object (in any implementation) may be both of type x and of
type y. Types a1 through an are an exhaustive union of type x if each aj is a
subtype of x, and any object of type x is necessarily of at least one of the types
aj; a1 through an are furthermore an exhaustive partition if they are also pairwise
disjoint.
- The type t is a supertype of every type whatsoever. Every object is of
type t.
- The type nil is a subtype of every type whatsoever. No object is of
type nil.
- The types cons, symbol, array, number, character, hash-table,
readtable, package, pathname, stream, random-state, and any
single other type created by defstruct or defclass are pairwise disjoint.
Type function is disjoint from the types cons, symbol, array,
number, and character.
The type compiled-function is a subtype of function;
implementations are free to define other subtypes of function.
- The types real and complex are pairwise disjoint subtypes of
number.
___________________________________________________________
Rationale: It might be thought that real and complex should form an exhaustive
partition of the type number. This is purposely avoided here in order to permit
compatible experimentation with extensions to the Common Lisp number system.
___________________________________________________________________________________________________________
- The types rational and float are pairwise disjoint subtypes of real.
__
Rationale: It might be thought that rational and float should form an exhaustive
partition of the type real. This is purposely avoided here in order to permit compatible
experimentation with extensions to the Common Lisp number system.
___________________________________________________________________________________________________________
- The types integer and ratio are disjoint subtypes of rational.
_________
Rationale: It might be thought that integer and ratio should form an exhaustive
partition of the type rational. This is purposely avoided here in order to permit
compatible experimentation with extensions to the Common Lisp rational number
system.
___________________________________________________________________________________________________________
Types fixnum and bignum do in fact form an exhaustive partition of the
type integer; more precisely, they voted to specify that the type bignum is by
definition equivalent to (and integer (not fixnum)). This is consistent with
the first edition text in section 2.1.1.
I interpret this to mean that implementators could still experiment with such
extensions as adding explicit representations of infinity, but such infinities would
necessarily be of type bignum.
- The types short-float, single-float, double-float, and long-float
are subtypes of float. Any two of them must be either disjoint or
identical; if identical, then any other types between them in the above
ordering must also be identical to them (for example, if single-float
and long-float are identical types, then double-float must be identical
to them also).
- The type null is a subtype of symbol; the only object of type null is
nil.
- The types cons and null form an exhaustive partition of the type list.
- The type standard-char is a subtype of base-char. The types
base-char and extended-char form an exhaustive partition of
character.
- The type string is a subtype of vector; it is the union of all types
(vector c) such that c is a subtype of character.
- The type bit-vector is a subtype of vector, for bit-vector means
(vector bit).
- The types (vector t), string, and bit-vector are disjoint.
- The type vector is a subtype of array; for all types x, the type (vector
x) is the same as the type (array x (*)).
- The type simple-array is a subtype of array.
- The types simple-vector, simple-string, and simple-bit-vector are
disjoint subtypes of simple-array, for they mean (simple-array t
(*)), the union of all types (simple-array c (*)) such that c is a
subtype of character, and (simple-array bit (*)), respectively.
- The type simple-vector is a subtype of vector and indeed is a subtype
of (vector t).
- The type simple-string is a subtype of string. (Note that although
string is a subtype of vector, simple-string is not a subtype of
simple-vector.)
____________________________________________________
Rationale: The hypothetical name simple-general-vector would have been
more accurate than simple-vector, but in this instance euphony and user
convenience were deemed more important to the design of Common Lisp than a rigid
symmetry.
___________________________________________________________________________________________________________
- The type simple-bit-vector is a subtype of bit-vector. (Note that
although bit-vector is a subtype of vector, simple-bit-vector is not
a subtype of simple-vector.)
- The types vector and list are disjoint subtypes of sequence.
- The types random-state, readtable, package, pathname, stream,
and hash-table are pairwise disjoint.
random-state, readtable, package, pathname, stream, and hash-table
are pairwise disjoint from a number of other types as well; see note above.
- The types two-way-stream, echo-stream,
broadcast-stream, file-stream, synonym-stream, string-stream,
and concatenated-stream are disjoint subtypes of stream.
- Any two types created by defstruct are disjoint unless one is a
supertype of the other by virtue of the :include option.