[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re: I agree with Jonl that the right thing to do is to say that
attempting to store a type-improper value in a slot should signal
an error. . . .
That's just a bit beyond what my opinion on this matter was.
Date: Wed, 27 Jan 88 03:00:04 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
. . .
My preference as stated before is to
prohibit a rule *requiring* checking of slot values, except that under the
extremal safety settings such checking *may* be required. Note that this
phrasing grants permission for an implementation to do type-checking at all
safety levels, if it so chooses.
I think one reason we have spent so much time going around on this matter
is that Moon started out by attacking the wrong paragraph -- the one from
page 13 in which the phrase something like "because type checking occurs
only under the most strict safety options and in the interpreter". The
sole purpose of that paragraph was to warn the reader that a slot's value
may in fact violate its :type specification; that paragraph by itself did
not carry the burden of saying that slots must be type-checked.
As the story unfolded, he really wanted to attack the part with the phrase
you (erroneously) attribute to me -- "Attempting to store a value in a
slot that does not satisfy the type should signal an error" -- and have it
relaxed from the "should" imperative.
CLtL itself is very weak in specifying the cases where an error "should"
be signalled, particularly in regard to array and structure updates (and
makes virtually no distinction between the various compiler safety levels).
A programmer used to the surety of a strongly-typed language finds this
situation intolerable; consequently, I've put this issue into my file
of things which haven't yet reached the Cleanup committee but ought to.
If ever such an issue should be approved by X3J13, then it most certainly
would apply to CLOS slot stores also.
-- JonL --