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.