[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Common-lisp-object-system@SAIL.Stanford.EDU
- Subject: Typechecking
- From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
- Date: 27 Jan 88 2128 PST
I think Moon must have gotten a bad chapter 1, because I cannot find the
quote he mentions in the file that I consider to be the definitive version.
The closest I can come is this:
``Because an implementation is required to check the type of the value
being stored in a slot only under the safest compiler safety setting and in the
interpreter, the value in a slot might fail to satisfy its type constraint.''
I believe this clearly states that violating the type constraint should
signal an error. There is no particularly pretty way to use the ``should
signal an error'' phrase here, so I expanded the definition of the phrase
inline. The use of the word ``only'' in the dependent clause beginning
with ``because'' combines with that ``because'' to state that the reason
that the value of the slot might fail to live up to the constraint is that
an implementation may or may not check the type on initialization and
The choices we have available to us are to require checking in all
cases, to require checking in at least the safest compiler compilation
setting and the interpreter, or to let the results be undefined. Stock
hardware people reject the first, and special-purpose people reject the last
(they want the results to be defined - to signal an error). Therefore, it
has to be ``should signal an error.'' We agreed long ago to abide by this
error terminology, and I won't accept backing down on that now.
About 2 or 3 paragraphs above the quote I reproduced is the following
statement about the :type option:
``Attempting to store a value in a slot which does not satisfy the type
should signal an error.''