Re: Type-checking of slot values

[Patrick H Dussud <DUSSUD@jenner.csc.ti.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.

I agree.

     Date: Tue, 26 Jan 88 01:28:37 PST
     From: Jon L White <edsel!jonl@labrea.stanford.edu>
     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
     checking.  

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.

Patrick.