Type-checking of slot values

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

   Date: Tue, 26 Jan 88 11:31 EST
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
      Date: Tue, 26 Jan 88 01:28:37 PST
      From: 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.  
   If you read CLOS pages 1-6 and 2-23, that is clearly not the case.  The
   second one requires every implementation to signal an error in certain
   circumstances.

Just what is it that you think is "clearly not the case"?   The two 
alternative specifications above were under discussion -- not error checking 
in general -- and nothing I've seen so far changes the meaning of either of 
those two sentences.  In fact, CLOS pages 1-6 and 2-23 support exactly the 
summary I proposed, but which you omitted from your excerpt of my message:
	". . . 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."
See also my comments below on Patrick's confusion betewen "if" and "only-if".

      ...nor does it even
      imply that an implementation has to provide "compiler safety settings".

   CLtL page 160.

Sorry, that page doesn't say that *any* declaration at all has to affect
the compiler's behaviour.  [I suppose we could keep this discussion up if 
someone wants to imagine yet more unspoken meanings for "provide", but I'll 
gracely bow out now].

   I'd rather not get into a discussion on this mailing list of whether
   Lisp should or should not be changed into a strongly-typed language.  That
   belongs on some other list.

No one has ever suggested changeing Lisp into a strongly-typed language.  We
can cut this discussion short by eliminating the bogeymen.

   Date: Tue, 26 Jan 88  08:45:39 CST
   From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>

       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." 

   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).

Not as I read it!  The phrase "<foo> is required only when <bar>" is definitely
not equivalent to the phrase  "<foo> is required whenever <bar>".  Could
this variant reading of "only when" be the source of all our disagreement?

   I don't think that the type checking has anything to do with good
   performance. The important thing for good performance is that . . .

   Patrick.


Unfortunately, "type checking" does have something to do with performance,
if you take the view of the structured programming folks.  That view says
that *no* data access is permitted unless it is proven correct; it doesn't
forbid runtime checks, but it biases towards compile time checks.  These
folks are particularly aghast at languages like C where you have virtually 
no compile time type checking, and none at all a runtime.  The phrase
"type checking" is a slogan that often differentiates these two camps.

There *appears* to be a runtime cost for runtime type checking, and this is
not just a Lisp issue [however, few special-purose machines for languages
like functional-programming ML, or for super-strongly-typed languages like 
Mesa, seem to have been commercial successes].  CLtL permits implementations 
to range anywhere between the extremes of "No access until proven correct"
and "Anything goes".  Caveat Luser. 

It would be inconsistent with this CL philosophy for CLOS to insert a bias, 
or requirement, for the former more "costly" approach.



-- JonL --


P.S. Since Moon failed to resist carping about the SPARC, I'll fail to resist
     making the following challenge:

     "SPARC does not have a Common Lisp + instruction, nor does it have any
      special-purpose hardware for Lisp.  Neither does the 'other' RISC chip
      that nobody knows about.  I'll debate this issue anytime, anyplace."

[but hopefully, not here in the mails of CLOS].