Typechecking

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

    Date: 27 Jan 88  2128 PST
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    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.

It's there, and you quoted it yourself.  You were just misled because I
extracted part of a sentence without putting in ellipses.  But let's
forget that.  The important quote is "Attempting to store a value in a
slot that does not satisfy the type should signal an error", as you
pointed out.  I never should have drawn attention to the later quote
which is just amplifying on this.

Chapter 1 defines "should signal an error" to mean "an error will be
signaled at least in the interpreter and in code compiled under the
safest compiler safety optimization level."  I still object to what
chapter 1 currently says about the :type slot option.  To rephrase what
I said before:

Sometime between August and November the definition of the :type slot
option was changed from "An implementation may or may not choose to
check the type of the new value when initializing or assigning to a
slot" to "Attempting to store a value in a slot that does not satisfy
the type should signal an error".  It is not consistent with CLtL's
definition of the :type slot option in defstruct and the type
declaration for variables.  Violation of those type constraints "is an
error" according to CLtL.

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

This "special-purpose person" does not -- I want type-checking of slot
values to be optional.  I want the results to be undefined, as that
phrase is defined in the front of chapter 1.  What I -really- want is
for CLOS and the rest of Common Lisp to be consistent on this issue.  As
long as the rest of Common Lisp continues to say that the results are
undefined, CLOS should say the same.

								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.

I don't object to the terminology for describing the semantics, only to
which semantics was chosen.

Is there anyone who actually wants "should signal an error" and won't
accept "results are undefined"?  If not, let's change it.  If so, that
person should be agitating to change Common Lisp as well.