"Strong typing vs. strong testing"
Ian Collins
ian-news at hotmail.com
Thu Sep 30 09:03:14 CEST 2010
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.
--
Ian Collins
More information about the Python-list
mailing list