[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Type-checking of slot values
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Re: Type-checking of slot values
- From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
- Date: Tue, 26 Jan 88 08:45:39 CST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Msg of Mon, 25 Jan 88 22:18 EST from "David A. Moon" <Moon@scrc-stony-brook.arpa>
- In-reply-to: Msg of Tue, 26 Jan 88 01:28:37 PST from Jon L White <email@example.com>
Date: Mon, 25 Jan 88 22:18 EST
From: "David A. Moon" <Moon@scrc-stony-brook.arpa>
Subject: Type-checking of slot values
Reference: pages 1-13 and 2-23 of 20 Jan 88 draft.
CLtL p.158, p.310, p.6.
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 "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." I don't think
this change was every publically discussed.
I don't remember such discussion.
It's perfectly legitimate to argue against the current definition of
type declarations in Common Lisp. I have no problem with that.
However, I don't think it's appropriate for this issue to be decided
by CLOS rather than by CL, nor do I think it a good idea for type
declarations in CLOS to have different semantics from type declarations
in the rest of CL.
I feel the definition of CLOS's :type slot-option must be changed back,
unless there is an agreed upon change to Common Lisp to accompany it.
Date: Tue, 26 Jan 88 01:28:37 PST
From: Jon L White <firstname.lastname@example.org>
Subject: 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
If I read (2), a type check is required when the SAFETY compiler switch
is set to 3. No such thing is said in (1).
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 believe that (1) is close to what CLtL says (p. 158), agrees with
CLtL type declaration semantics, and is quite specific about it.
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.
I don't think that it is up to us [CLOS working group] to decide this.
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:
I don't think that the type checking has anything to do with good
performance. The important thing for good performance is that an
implementation can optimize slot access based on :type information. I
don't want to take that away from CLOS, or CLtL.