On Sep 30, 1:38 pm, Lie Ryan <lie.1...@gmail.com> 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.
I have not programmed in Haskell that much, but I think Haskell inferences type "Integer" (the infinite precision) by default and not "Int" (finite precision) type for the integers. So, the programmer who specifically mentions "Int" in the signature of the function, is basically overriding this default behavior for specific reasons relevant to the application, for example, for performance. I think Haskell's way is the right. It is providing "safe behavior" as default and at the same time treating programmer as adults, at least in this case. I think dynamic languages are attractive because they make programs less verbose. But, statically typed languages with type inference (Haskell, OCaML, Scala, F#) is a very good compromise because they offer both type safety and succinctness. And when we need algorithms that should work the same independent of types, Haskell has typeclasses which are pretty intuitive, unlike the horrible C++ templates. -- http://mail.python.org/mailman/listinfo/python-list
