[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Type-checking of slot values
The two sentences you are comparing here aren't really that different:
(1) "An implementation may or may not choose to check the type of the
new value when initializing or assigning to a slot"
(2) "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."
As I read these two, they require absolutely nothing in the way of error
The second one seems to be trying to constrain future requirements; that is,
the requirement for type checking will never be more strict than requireing
it at the most strict compiler safety settings. That certainly doesn't say
that an implementation can't do it at other compiler settings, nor does it
even imply that an implementation has to provide "compiler safety settings".
Further, it doesn't introduce any inconsistency with Common Lisp semantics of
variable declarations [because both wordings, at present, require nothing].
I vaguely remember this issue being thrashed out on CLOS mailing list just
after there was a round of complaints on the general common-lisp mailing
list about the loopholes in CLtL's frequent phrase "it is an error". If
anything, there seemed to be consensus *not* to leave CLOS so underspecified
that any old tune could be played on its fiddle. The alternative of requiring
safety checking on every slot initialization or updating is clearly
incompatible with the pages of CLtL you cite (p.310, p.158 and p.6), and with
the performance goals of a majority of Common Lisp vendors.
[I know Dick had a strong interest in seeing this loophole plugged up; he is
out of town now and may not be able to give his views for a few days -- I'm
sorry if I've not remembered his "side" of it correctly].
Now, concerning your apology for carping presumably about the phrase "safest
compiler safety setting":
Perhaps this is my bias that type declarations are only a crutch for
crippled machines showing . . .
There is a whole world out there that firmly *believes* in structured,
strongly-typed programming. The roots of their beliefs have nothing at all
to do with machine architectures, crippled or otherwise. Of course, some
would say that their philosophy makes better performance *possible* on
standard ("stock") hardware, but that really isn't the whole issue. The
question for us really is whether or not Common Lisp will acknowledge and
accept some of this "strongly typed" technology, and put it to good work in
a fruitful way.
If CLOS is defined is such a way that acceptable performance is only
achievable on "special purpose" hardware [e.g., a defclass is far too
slow to be a substitute for defstruct], then I suspect it will be subject
to Deutsch's Dictum:
"Any computer language that runs on only one manufacturer's
hardware is doomed to failure . . .
--- unless that manufacturer is IBM."
[Quotation of opinion given by L. Peter Deutsch in public forums during 1983
-- JonL --