Re: OO, C++, and something much better!

[fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson)]

Alan Lovejoy <alovejoy@concentric.net> 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 <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.