Error Terminology

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 24 Mar 88  2155 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    ....
    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.''

If I understand what you're saying, the difference is that with the first description,
and implementation is allowed to halt and catch fire if you store a bignum into a slot
that is declared :type fixnum, while with the second description the implementation
is not; it's required either to ignore the type declaration or to signal an error.
Personally, I don't have strong feelings about type declarations, other than that
they should be removed from Common Lisp entirely, so I'm not really in a position
to choose between those two alternatives.  However, if the purpose of type declarations
is to allow optimization through specialized implementation techniques, I would
think that you would not want to deny the implementation the freedom that the
first description allows.

Well, that wasn't very clear.  What I mean is, the first description allows a
slot to be implemented in a special type-specific way, as one might implement
a local variable.  The second description requires slots to be implemented
in the general way that can hold all objects, but allows the type declaration
to be used only for two purposes: to propagate that type through code that reads
the slot, thereby doing type-specific optimization on that code, and to add a
type check to code that writes the slot, signalling an error if the declaration
is violated.