[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Type-checking of slot values
- To: labrea!Bobrow.pa%Xerox.COM@labrea.Stanford.EDU
- Subject: Type-checking of slot values
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Wed, 27 Jan 88 03:00:04 PST
- Cc: labrea!Common-Lisp-Object-System%SAIL.STANFORD.EDU@labrea.Stanford.EDU
- In-reply-to: Danny Bobrow's message of 26 Jan 88 18:48 PST <880126-184910-2818@Xerox>
re: Would it be better to say:
(2) "An implementation is allowed to check the type of the value being
stored in a slot only under the safest compiler safety setting and
in the interpreter."
This would stop it from being checked at other times. What is the intent?
This may be the interpretation that Moon et al are objecting to; and I
wouldn't approve of it either. I certainly read the offending sentence
of CLOS 1-13
"<foo> is required only when <bar>"
as if it were
"<foo> is required at most when <bar>, and nothing is said
about the case of when not <bar>."
The intent of that paragraph is only to say that a slot value is permitted
to violate its corresponding :type specifier.
With respect to type-checking the slot values, there is clearer language
elsewhere in the CLOS documents; and it isn't nearly so ambiguous as CLtL's
universal excuse "it is an error". 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.
Incidentally, I would propose a benchmark of using defclass for defstruct,
and see if there is *any* mode where the user suffers no slowdown [:type
specifiers aren't the only hinderence to success here!]. Conversely, there
should be a test case that asks whether there is *any* mode where all slot
:type specifiers are always satisfied.
Linda thinks Dick put in the wording that Dave proposes to change; maybe
we should give him a chance to explain his intent.
-- JonL --