From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, WEIRD_PORT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) Subject: Re: OO, C++, and something much better! Date: 1997/01/24 Message-ID: <5c9a4d$sha$1@goanna.cs.rmit.EDU.AU>#1/1 X-Deja-AN: 211845729 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <5c4fr0$27j@mulga.cs.mu.OZ.AU> <32E67751.4AFC@parcplace.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object nntp-posting-user: ok Date: 1997-01-24T00:00:00+00:00 List-Id: Eric Clayberg writes: >Having been involved with commercial Smalltalk development for quite a >few years, I tend to agree with Alan that the percentage of actual type >related errors in Smalltalk programs is less that 2% - .... >experience. I have written over several hundred thousand lines of >... Most "message not >understood" errors, in fact, are to the nil object in Smalltalk (the >moral equivalent of a null pointer in C). These are not really type >errors, but usually problems with improper initializations or premature >discarding of data. These are logic problems; not type problems. A >static type checker would catch them no better in Smalltalk than it >would in C++. Sorry, there is a misconception here. There _are_ type systems, several in fact, which _would_ catch such errors. For example, I believe the *type checker* in Dr Scheme will catch many of these errors. Suppose you have a function f which is defined on some set of values v, and there is an expression (f x). The type checker determines a set of possible values p for x. p subset v => static check passed. p intersect v empty => certain type error neither of the above => run time check needed The Dr Scheme checker uses something called "set based analysis". I believe that the Stalin compiler does something similar. Thing is, "type error" is a term in the language of SYMPTOMS, "logic error" is a term in the language of MISTAKES. A type error may very well be a symptom of a logic error, why not? The fact that a C++ compiler cannot detect null pointer errors as type errors is a fact about C++ specifically, not a fact about static type systems in general. I once designed a type system in which ^T meant non-null pointer to T and ?T meant possibly-null pointer to T. (My main reason for this was optimisation; I wanted safety, but didn't want to pay the price of null checks over and over again.) In that type system, var x: ?T; y: ^T := new T; x := y; -- always legal y := x; -- needs a run time check x := null; -- always legal y := null; -- statically illegal What's more, there is a static checker for C called LClint, available free from http://larch-www.lcs.mit.edu:8001/larch/lclint/ that _does_ perform static checks for null pointers, and _does_ check for initialisation. Of course, the kinds of data flow analysis that LClint does (or more truthfully, approximates) are hard to do in a "fluid" language like Lisp or Smalltalk, where what the program _is_ can change at run time. The basic issue there is really dynamic *programs* in Lisp, R, S, Prolog, Smalltalk, &c vs static *programs* in C, Ada, &c. -- My tertiary education cost a quarter of a million in lost income (assuming close-to-minimum wage); why make students pay even more? Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.