dpans/concept-types.tex

% -*- Mode: TeX -*-

% At Barmar's suggestion, and by consensus of Quinquevirate, the type hierarchy
% diagrams, which were quite hard to maintain and anyway unnecessary, were removed.
% The removed text is in
%   Stony-Brook.SCRC.Symbolics.COM:>ANSI-CL>spec>archive>source>type-hierarchy-diagrams.tex
% -kmp 10-Jun-91

\beginsubSection{Data Type Definition}

%% No longer true.
%Following is a description of each \clisp\ \term{type}.

% %This kind of info belongs in the descriptions of the ftype{...} labels.
% %New. -kmp
% % Barmar: Relate to the use of "Type" vs "System Class" in following descriptions.
% % Barrett: Perhaps safer to say "Where explicitly noted..."
% % KMP: In fact, I think the paragraph should just disappear, since in all cases where 
% %  something is both a type and a class, there is a Class Precedence List section
% %  in its definition, and the ordering info is already well-defined.
% % Barmar: If there's always a CPL given, then I agree.
%% Removed. -kmp 15-Feb-92
% Except as otherwise noted,
% every \term{symbol} naming a \term{type} 
% defined in this specification is also the name of a \term{class} that implements
% the \term{type}.  In cases where there is a corresponding \term{class},
% the order of its \term{class precedence list} is consistent with the order
% of the subtype relationships given for the \term{type}.

Information about \term{type} usage is located in 
the sections specified in \figref\TypeInfoXrefs. 
\figref\ObjectSystemClasses\ lists some \term{classes} 
that are particularly relevant to the \CLOS.
\figref\StandardizedConditionTypes\ lists the defined \term{condition} \term{types}.

\DefineFigure{TypeInfoXrefs}
\showtwo{Cross-References to Data Type Information}{
\hfil\b{Section} & Data Type \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
\secref\Classes                 & Object System types                \cr
\secref\Slots                   & Object System types                \cr
\secref\Objects                 & Object System types                \cr
\secref\GFsAndMethods           & Object System types                \cr
\secref\ConditionSystemConcepts & Condition System types             \cr
\chapref\TypesAndClasses        & Miscellaneous types		     \cr
\chapref\Syntax                 & All types---read and print syntax  \cr
%Nothing really useful here. -kmp 17-Oct-91
%\secref\ReaderConcepts         & All types---read syntax            \cr
\secref\TheLispPrinter          & All types---print syntax           \cr
\secref\Compilation             & All types---compilation issues     \cr
}

%!!! Insert table of Type Specifiers like AND, OR, NOT... 
%    from top of DICT-TYPES ? -kmp 17-Oct-91

\endsubSection%{Data Type Definition}

\beginsubSection{Type Relationships}
\DefineSection{TypeRelationships}

\beginlist

\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\itemitem{\bull}
\Thetypes{cons}, \typeref{symbol}, \typeref{array}, \typeref{number},
\typeref{character}, \typeref{hash-table}, 
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
\typeref{function},
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
\typeref{readtable}, \typeref{package}, \typeref{pathname}, \typeref{stream}, 
\typeref{random-state}, \typeref{condition}, \typeref{restart},
and any single other \term{type} created by \macref{defstruct},
%Added per suggestion of Barrett:
\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
\issue{CLOS-CONDITIONS:INTEGRATE}
\macref{define-condition},
\endissue{CLOS-CONDITIONS:INTEGRATE}
\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
or \macref{defclass} are \term{pairwise} \term{disjoint}, 
except for type relations explicitly established by specifying 
\term{superclasses} in \macref{defclass} 
\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
\issue{CLOS-CONDITIONS:INTEGRATE}
or \macref{define-condition}
\endissue{CLOS-CONDITIONS:INTEGRATE}
\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
or the \kwd{include} option of \macref{destruct}.

%The following will be left out of the standard.
%% 2.15.0 6
%\itemitem{\bull} \typeref{Cons}, \typeref{symbol},
%\typeref{array}, \typeref{number}, and \typeref{character}
%are \term{pairwise} \term{disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}

\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%The following will be left out of the standard.
%% 2.15.0 27
%\itemitem{\bull}  \typeref{hash-table}, \typeref{readtable}, 
%\typeref{package}, \typeref{pathname},
%\typeref{stream}, and \typeref{random-state} are 
%\term{pairwise} \term{disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}

%% 2.15.0 28
\itemitem{\bull} Any two \term{types} created by \macref{defstruct} are 
\term{disjoint} unless
one is a \term{supertype} of the other by virtue of
the \macref{defstruct} \kwd{include} option.

\editornote{KMP: The comments in the source say gray suggested some change
from ``common superclass'' to ``common subclass'' in the following, but the
result looks suspicious to me.}
%!!! Barrett says: It fits the glossary definition of disjoint, i.e., no common
% elements.  However, I think that is broken.
%
% In places where we have specified disjointness requirements, all we really seem to
% be intendeing is that two types C1 and C2 are disjoint if neither is a subtype of
% the other.

\itemitem{\bull}
Any two \term{distinct} \term{classes} created by \macref{defclass} 
% added --sjl 7 Mar 92
or \macref{define-condition}
are \term{disjoint} unless they have a common \term{subclass} or
one \term{class} is a \term{subclass} of the other.
%% The preceding text by Moon replaces the following...
% %% "common superclass" changed to "common subclass" as suggested by Gray
% \itemitem{\bull} Any two \term{classes} created by \macref{defclass} 
% are \term{disjoint} unless they have a common \term{subclass} or
% one \term{class} is a \term{superclass} of the other.
% %Any two \term{classes}
% %created by \macref{defclass} are \term{disjoint}
% %unless they have a common \term{superclass}."  {That assumes that
% %our definition of superclass says every class is a superclass of
% %itself, which I think is the case, but did not check.}
% %
% %RPG suggestion follows:
% %\itemitem{\bull} Any type created by defstruct or defclass is guaranteed
% %to be disjoint from all other types unless subclass or :include is used.

\issue{COMMON-TYPE:REMOVE}
%The following will be deleted from the standard:
%
%% 2.15.0 29
%\itemitem{\bull} An \term{exhaustive union} for 
%\thetype{common} is formed by \typeref{cons}, \typeref{symbol},
%\f{(array x)} where \f{x} is either \typeref{t} or a \term{subtype} of \typeref{common},
%\typeref{string}, \typeref{fixnum}, \typeref{bignum}, \typeref{ratio},
%\typeref{short-float}, \typeref{single-float}, \typeref{double-float}, \typeref{long-float},
%\f{(complex x)} where \f{x} is a \term{subtype} of \typeref{common},
%\typeref{standard-char}, \typeref{hash-table}, \typeref{readtable}, 
%\typeref{package}, \typeref{pathname},
%\typeref{stream}, \typeref{random-state},
%and all \term{types} created by the user via \macref{defstruct}.
%An implementation cannot add \term{subtypes} to \typeref{common}.
\endissue{COMMON-TYPE:REMOVE}

%% Following is suggested by Moon, rewording of a clause in 88-002R.
\itemitem{\bull} 
An implementation may be extended to add other \term{subtype}
relationships between the specified \term{types}, as long as they do
not violate the type relationships and disjointness requirements
specified here.  An implementation may define additional \term{types}
that are \term{subtypes} or \term{supertypes} of any
specified \term{types}, as long as each additional \term{type} is
a \subtypeof{t} and a \supertypeof{nil} and the disjointness requirements
are not violated.
 
\issue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}
At the discretion of the implementation, either \typeref{standard-object}
or \typeref{structure-object} might appear in any class precedence list
for a \term{system class} that does not already specify either 
\typeref{standard-object} or \typeref{structure-object}.  If it does,
it must precede \theclass{t} and follow all other \term{standardized} \term{classes}.
\endissue{TYPE-OF-AND-PREDEFINED-CLASSES:UNIFY-AND-EXTEND}

\endlist                                     

\endsubSection%{Type relationships}

%% Type Specifiers
\beginsubSection{Type Specifiers}
\DefineSection{TypeSpecifiers}

\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%Discussion of difference between "type specifiers for declaration"
%and "type specifiers for discrimination" removed.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}

%% 4.1.0 1
\term{Type specifiers} can be \term{symbols}, \term{classes}, or \term{lists}.
\figref\StandardizedAtomicTypeSpecs\ lists \term{symbols} that are
  \term{standardized} \term{atomic type specifiers}, and
\figref\StandardizedCompoundTypeSpecNames\ lists
 \term{standardized} \term{compound type specifier} \term{names}.
For syntax information, see the dictionary entry for the corresponding \term{type specifier}.
It is possible to define new \term{type specifiers} using
 \macref{defclass},
 \macref{define-condition},
 \macref{defstruct}, 
or
 \macref{deftype}.

\issue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}
\issue{STREAM-ACCESS:ADD-TYPES-ACCESSORS}

\DefineFigure{StandardizedAtomicTypeSpecs}
%% 4.3.0 4
\displaythree{Standardized Atomic Type Specifiers}{
arithmetic-error&function&simple-condition\cr
array&generic-function&simple-error\cr
atom&hash-table&simple-string\cr
base-char&integer&simple-type-error\cr
base-string&keyword&simple-vector\cr
bignum&list&simple-warning\cr
bit&logical-pathname&single-float\cr
bit-vector&long-float&standard-char\cr
broadcast-stream&method&standard-class\cr
built-in-class&method-combination&standard-generic-function\cr
cell-error&nil&standard-method\cr
character&null&standard-object\cr
class&number&storage-condition\cr
compiled-function&package&stream\cr
complex&package-error&stream-error\cr
concatenated-stream&parse-error&string\cr
condition&pathname&string-stream\cr
cons&print-not-readable&structure-class\cr
control-error&program-error&structure-object\cr
division-by-zero&random-state&style-warning\cr
double-float&ratio&symbol\cr
echo-stream&rational&synonym-stream\cr
end-of-file&reader-error&t\cr
error&readtable&two-way-stream\cr
extended-char&real&type-error\cr
file-error&restart&unbound-slot\cr
file-stream&sequence&unbound-variable\cr
fixnum&serious-condition&undefined-function\cr
float&short-float&unsigned-byte\cr
floating-point-inexact&signed-byte&vector\cr
floating-point-invalid-operation&simple-array&warning\cr
floating-point-overflow&simple-base-string&\cr
floating-point-underflow&simple-bit-vector&\cr
}

\endissue{STREAM-ACCESS:ADD-TYPES-ACCESSORS}
\endissue{CHARACTER-VS-CHAR:LESS-INCONSISTENT-SHORT}

\indent               
%% 4.2.0 1         
If a \term{type specifier} is a \term{list}, the \term{car} of the \term{list} 
is a \term{symbol}, and the rest of the \term{list} is subsidiary
\term{type} information.  Such a \term{type specifier} is called 
a \newterm{compound type specifier}.
Except as explicitly stated otherwise,
the subsidiary items can be unspecified.
The unspecified subsidiary items are indicated
by writing \f{*}.  For example, to completely specify
a \term{vector}, the \term{type} of the elements
and the length of the \term{vector} must be present.

\code
 (vector double-float 100)
\endcode
The following leaves the length unspecified:

\code
 (vector double-float *)
\endcode
The following leaves the element type unspecified:

\code
 (vector * 100)                                      
\endcode
Suppose that two \term{type specifiers} are the same except that the first
has a \f{*} where the second has a more explicit specification.
Then the second denotes a \term{subtype} 
of the \term{type} denoted by the first.

%% 4.2.0 2
If a \term{list} has one or more unspecified items at the end, 
those items can be dropped.
If dropping all occurrences of \f{*} results in a \term{singleton} \term{list},
then the parentheses can be dropped as well (the list can be replaced
by the \term{symbol} in its \term{car}).  
For example,                       
{\tt (vector double-float *)}                    
can be abbreviated to {\tt (vector double-float)},               
and {\tt (vector * *)} can be abbreviated to {\tt (vector)} 
and then to 
{\tt vector}.

\issue{REAL-NUMBER-TYPE:X3J13-MAR-89}
%Syntax info removed to make the document smaller and more modular. -kmp 20-Oct-91
%Added CONS per Dalton #10 (first public review). -kmp 10-May-93
\DefineFigure{StandardizedCompoundTypeSpecNames}
\displaythree{Standardized Compound Type Specifier Names}{
and&long-float&simple-base-string\cr
array&member&simple-bit-vector\cr
base-string&mod&simple-string\cr
bit-vector&not&simple-vector\cr
complex&or&single-float\cr
cons&rational&string\cr
double-float&real&unsigned-byte\cr
eql&satisfies&values\cr
float&short-float&vector\cr
function&signed-byte&\cr
integer&simple-array&\cr
}
\endissue{REAL-NUMBER-TYPE:X3J13-MAR-89}

\Thenextfigure\ show the \term{defined names} that can be used as 
\term{compound type specifier} \term{names}
but that cannot be used as \term{atomic type specifiers}.

\displaythree{Standardized Compound-Only Type Specifier Names}{
and&mod&satisfies\cr
eql&not&values\cr
member&or&\cr
}


%% 4.7.0 1
New \term{type specifiers} can come into existence in two ways.
\beginlist
\itemitem{\bull} 
 Defining a structure by using \macref{defstruct} without using
 the \kwd{type} specifier or defining a \term{class} by using 
 \macref{defclass} 
% added --sjl 7 Mar 92
 or \macref{define-condition}
 automatically causes the name of the structure 
 or class to be a new \term{type specifier} \term{symbol}.
\itemitem{\bull} 
 \macref{deftype} can be used to define \newtermidx{derived type specifiers}{derived type specifier},
 which act as `abbreviations' for other \term{type specifiers}.
\endlist

A \term{class} \term{object} can be used as a \term{type specifier}. 
When used this way, it denotes the set of all members of that \term{class}.

\Thenextfigure\ shows some \term{defined names} relating to 
\term{types} and \term{declarations}.

% I added SUBTYPEP, TYPEP, DEFINE-CONDITION.  --sjl 7 Mar 92
\DefineFigure{TypesAndDeclsNames}
\displaythree{Defined names relating to types and declarations.}{
coerce&defstruct&subtypep\cr
declaim&deftype&the\cr
declare&ftype&type\cr
defclass&locally&type-of\cr
define-condition&proclaim&typep\cr
}

\Thenextfigure\ shows all \term{defined names} that are \term{type specifier} \term{names},
whether for \term{atomic type specifiers} or \term{compound type specifiers};
this list is the union of the lists in \figref\StandardizedAtomicTypeSpecs\ 
and \figref\StandardizedCompoundTypeSpecNames.

\DefineFigure{StandardizedTypeSpecifierNames}
\displaythree{Standardized Type Specifier Names}{
and&function&simple-array\cr
arithmetic-error&generic-function&simple-base-string\cr
array&hash-table&simple-bit-vector\cr
atom&integer&simple-condition\cr
base-char&keyword&simple-error\cr
base-string&list&simple-string\cr
bignum&logical-pathname&simple-type-error\cr
bit&long-float&simple-vector\cr
bit-vector&member&simple-warning\cr
broadcast-stream&method&single-float\cr
built-in-class&method-combination&standard-char\cr
cell-error&mod&standard-class\cr
character&nil&standard-generic-function\cr
class&not&standard-method\cr
compiled-function&null&standard-object\cr
complex&number&storage-condition\cr
concatenated-stream&or&stream\cr
condition&package&stream-error\cr
cons&package-error&string\cr
control-error&parse-error&string-stream\cr
division-by-zero&pathname&structure-class\cr
double-float&print-not-readable&structure-object\cr
echo-stream&program-error&style-warning\cr
end-of-file&random-state&symbol\cr
eql&ratio&synonym-stream\cr
error&rational&t\cr
extended-char&reader-error&two-way-stream\cr
file-error&readtable&type-error\cr
file-stream&real&unbound-slot\cr
fixnum&restart&unbound-variable\cr
float&satisfies&undefined-function\cr
floating-point-inexact&sequence&unsigned-byte\cr
floating-point-invalid-operation&serious-condition&values\cr
floating-point-overflow&short-float&vector\cr
floating-point-underflow&signed-byte&warning\cr
}

\endsubSection%{Type Specifiers}