Pure functions must have no side effects. There is a subtle cause of side
effects on suposed pure functional code. It is the case of integer
overflow, as well as float or double overflow. I know, usual definition of
side-effect in software is to have different results on same inputs. But
seriously, don't you consider this result as a non desired effect?:
*Main> splitAt (div (4*10^10) (10^10)) "Hello, world"
("","Hello, world")
I think that a purely functional language must avoid this behaviour.
Otherwise, either the function `div` or the function `splitAt` is not
correctly defined, because it doesn't do what it should do.
Usually, an overflow problem is considered to be a beginner error. I don't
agree. Beginners are the people who try the more logical way to do things
with the less knowledge, so they are the best test for the design of a
programming language. If they read that Haskell is pure functional, it
should be true. Bounded types, like `Int`, `Word16` or `Float` produce
undesirable results, breaking some advantages of Haskell and functional
programming. But what is worst is that there are bounded types included in
Prelude, and they are used as type of arguments to basic functions included
in Prelude. This makes that, in many cases, the induced type is a bound
type and the program doesn't work the way that is programmed because of
`Int` overflow. Worst indeed, the compiler doesn't detect it as an error,
and the runtime system does not catch it as an exception. Worst indeed,
when the programmer asks experts on forums, they answer that the problem is
being a beginner :-) .
The most dangerous of that bounded types is `Int`. Several functions on
lists requires Int arguments. The problem is that other induced types are
erroneously `Int`, or you must use `fromInteger` to avoid a problem not
produced by you, you didn`t decide to use `Int`, you didn' decided such
optimization. The justification for using `Int` as default integer type use
to be performance and size memory. But there is not so much increase in
execution time or used memory if `Integer` is used instead. The potencial
problems and the hidden side-effect are much more worst than the benefits.
Today there exists very good arbitrary precision arithmetic algorithms that
makes the performance justification obsolete. I mean that the problem of
arithmetic optimization should be a problem for the compiler, but not for
the usual programmer. So, I think that arbitrary precision arithmetic must
be the default for Haskell. Bounded types must be out of Prelude, and they
should be used just for low level and expert programming.
That is tantamount to other proposals, like the algebraic numbers system,
the ticket #108 (make toEnum and fromEnum take and return Integers), and
some others.
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
