# Error Terminology

Earlier I mentioned that I had changed the wording surrounding the order
of evaluation of initforms to use the term unspecified.'' I suspect that
unspecified'' needs a definition, so here's an attempt. I think it is
different from undefined.''

When situation $S$ occurs, the results are unspecified.''

This terminology has the following meaning:

\beginlist

\item{\bull} The effects of this situation are not specified in
the \OS, but the effects are harmless.

\item{\bull} Implementations are allowed to specify the effects of
this situation.

\item{\bull} No portable program can depend on the effects of this
situation, and all portable programs are required to treat the situation
as unpredictable but harmless.

\endlist

********************************************************************

On a related note, I think that one of the uses of the term
undefined'' is suspect, though it is not on Moon's list of
suspect uses:

\item{\bull} The contents of a slot will always be of type {\tt
(and} $T\sub 1$ $\ldots$ $T\sub n${\tt )} where $T\sub 1 \ldots T\sub n$ are
the values of the {\bf :type} slot options contained in all of the slot
specifiers.  If no slot specifier contains the {\bf :type} slot option, the
contents of the slot will always be of type {\bf t}. The result
of attempting to store in a slot
a value that does not satisfy the type of the slot is undefined.''

The suspicion is that this ought to be described some other, less sinister
way:

\item{\bull} The type of a slot will always be {\tt
(and} $T\sub 1$ $\ldots$ $T\sub n${\tt )} where $T\sub 1 \ldots T\sub n$ are
the values of the {\bf :type} slot options contained in all of the slot
specifiers.  If no slot specifier contains the {\bf :type} slot option, the
type of the slot will always be {\bf t}.
No implementation is required to check that the value stored in a slot satisfies
the type of the slot, but implementations are allowed to extend the \OS\
to check such values and to use the type of a slot during compilation.''

-rpg-