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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: OO, C++, and something much better! Date: 1997/01/26 Message-ID: <5ce8t3$6gv@mulga.cs.mu.OZ.AU> X-Deja-AN: 212225229 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> <5caqo5$k5l@mulga.cs.mu.OZ.AU> <32E9BAAC. organization: Comp Sci, University of Melbourne newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-01-26T00:00:00+00:00 List-Id: Alan Lovejoy writes: >Fergus Henderson wrote: >> >> Here's a more detailed breakdown. > >To which I wish to add some comments and analysis: > >> syntax errors: 16 >> type errors: 83 >> - errors in type declarations: 13 > >Doesn't apply to Smalltalk. > >> - type errors other than errors in type declarations: 70 >> - syntax related: 14 >May or may not apply to Smalltalk. Can't >tell without more specifics. I gave some specifics below; these would not apply to Smalltalk. >> - wrong procedure name: 11 > >The Smalltalk compiler will complain when you compile >a method that sends a message with no implementors. >So this would only apply to those cases where the >"wrong" name matched that of some other method. >I would assume that all such errors out of 11 would be >caught by the Smalltalk compiler (about 99% would be >caught overall). Fair enough. >> - wrong constant name: 4 >> - wrong variable name: 4 > >Were these "wrong" names simply undeclared, >or declared but wrongly typed? In the case of the wrong constant names, I didn't record these distinctions, but my guess is that probably they were mostly simply undeclared (and hence would have been detected at compile time in Smalltalk). In the case of the wrong variable names, it's a little more complicated. In Mercury, variables do not need declarations. Most errors involving variables are caught by either singleton variable warnings and/or by mode errors (both of these are counted in the "others" category below). Three of these four cases caught by type checking involved using an incorrect name that was also the name of another variable. I think they would also have occurred in Smalltalk (and would not have been deteted until run time). The fourth case involved trying to use the same name for two different variables. I'm not sure whether that one would have occurred in Smalltalk. I guess it would depend on whether the programmer noticed that there was already a declaration for that variable. > How many of the >"wrongly typed" ones involved type differences >that don't matter in Smalltalk (ie, long vs. short >numbers, different types of Collection)? I doubt if there are any of these sort of errors. Mercury has a quite simple type system. For example, there is only one integer type in Mercury. Mercury is not C++. >I will ssume that >1 of these 8 errors would cause a Smalltalk program to >produce the wrong result or fail (the Smalltalk compiler >will catch any undeclared references, and about 92% of type >incompatibilities in C++ are cases that will "just work fine" >at runtime in a Smalltalk program). As mentioned above, I think that at least 3 of these 8 errors would occur in Smalltalk and not be caught by the compiler. >> - argument has wrong type: 7 > >How many of these involved type differences that don't >matter in Smalltalk? Probably none of them. >And how many were caused by the fact >that the Algol-style function call syntax makes it so easy >to get the arguments wrong? Again, probably none of them. > So I would estimate that of the 83 type errors, only 1 of them would > show up at runtime in a Smalltalk program. Well, I think your estimate is wrong. I would estimate that 11 of them would show up at runtime. This would more than double the total number of runtime errors. In addition, I estimate that there are probably another 9 errors in the "others" category, e.g. uninitialized variable errors, that are caught by static analysis in the Mercury compiler but which are unlikely to be caught by Smalltalk compilers. Furthermore, just as there are errors that occur only in Mercury, and not in Smalltalk, there are no doubt many errors that would occur only in Smalltalk, and not in Mercury. Obviously such errors aren't included in my list... > Other advantages of > Smalltalk would probably eliminate several of those 9 run time errors > (for example, more abstract code... I doubt this. Mercury code is generally very high-level already, and looking at the nature of the errors, it's hard to see how using a different language could help avoid all but one of them. One of the nine errors was caused by incorrect argument order (it wasn't caught by typechecking since the arguments were both the same type). That one might well have been avoided in Smalltalk. Three were errors in the program's output. - omitting the filename on one of the error messages - enclosing something in double quotes instead of in singe quotes - printing `foo()' rather than `foo' (parentheses should only have been used when there were arguments, but the program printed them even when there were no arguments) Four were serious semantic errors (logic bugs); these are all too complicated to explain concisely, but I can't imagine any programming language feature that would avoid them. One was a performance bug, caused by using an unnecessarily inefficient algorithm in the inner loop. -- Fergus Henderson | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.