"Strong typing vs. strong testing"

[Pascal J. Bourguignon]

Ian Collins <ian-news at hotmail.com> writes:

> On 09/30/10 06:38 PM, Lie Ryan wrote:
>>
>> The /most/ correct version of maximum() function is probably one written
>> in Haskell as:
>>
>> maximum :: Integer ->  Integer ->  Integer
>> maximum a b = if a>  b then a else b
>>
>> Integer in Haskell has infinite precision (like python's int, only
>> bounded by memory), but Haskell also have static type checking, so you
>> can't pass just any arbitrary objects.
>>
>> But even then, it's still not 100% correct. If you pass a really large
>> values that exhaust the memory, the maximum() could still produce
>> unwanted result.
>>
>> Second problem is that Haskell has Int, the bounded integer, and if you
>> have a calculation in Int that overflowed in some previous calculation,
>> then you can still get an incorrect result. In practice, the
>> type-agnostic language with *mandatory* infinite precision arithmetic
>> wins in terms of correctness. Any language which only has optional
>> infinite precision arithmetic can always produce erroneous result.
>>
>> Anyone can dream of 100% correct program; but anyone who believes they
>> can write a 100% correct program is just a dreamer. In reality, we don't
>> usually need 100% correct program; we just need a program that runs
>> correctly enough most of the times that the 0.0000001% chance of
>> producing erroneous result becomes irrelevant.
>>
>> In summary, in this particular case with maximum() function, static
>> checking does not help in producing the most correct code; if you need
>> to ensure the highest correctness, you must use a language with
>> *mandatory* infinite precision integers.
>
> Or using the new suffix return syntax in C++0x.  Something like
>
> template <typename T0, typename T1>
> [] maximum( T0 a, T1 b) { return a > b ? a : b; }
>
> Where the return type is deduced at compile time.

Indeed.  This is generic programming.   And it happens that in Lisp (and
I assume in languages such as Python), sinte types are not checked at
compilation time, all the functions you write are always generic
functions.

In particular, the property "arguments are not comparable" is not
something that can be determined at compilation time, since the program
may add a compare method for the given argument at run-time (if the
comparison operator used is a generic function).

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/