Type-checking of slot values

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

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.  

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 
and 1984].



-- JonL --