Jens Blanck writes:

On 1 April 2010 10:53, Ivan Lazar Miljenovic wrote:

...

Jens Blanck writes:

...

I was wondering if someone could give me some references to when and why the choice was made to default integral numerical literals to Integer rather than to Int in Haskell.

Seems to have been in 1998. I don't have a complete archive of the discussion, though, and I don't know where to find the Haskell 98 committee minutes on-line.

...

My guess is precision: some numeric calculations (even doing a round on some Double values) will be too large for Int values (at least on 32bit). Note that unlike Python, etc. Haskell doesn't allow functions like round to choose between Int and Integer (which is equivalent to the long type in Python, etc.).

Ints have perfect precision as long as you remember that it implements modulo arithmetic for some power of 2. I was hoping that the reason would be that Integers give more users what they expect, namely integers, instead of something where you can add two positive numbers and wind up with a negative number.

As I interpret the part of the discussion I have on file, there are two reasons: (1) as you hoped, because Integers are what people "expect": reasoning on Integers is more reliable -- you can't do induction on Int, for example, and people don't generally try to prove that they've implemented f x = the_f_they_originally_wanted x `mod` 2^32 (2) good language design. One of the things I've repeated over the years is that Int doesn't have to be part of the language (it's just another peculiar type that should be defined in a library) but Integer does, because without it there's no way to specify the meaning of an Integral constant¹. Jón [1] This isn't quite true; using subtyping one could make Integral constants into [Digit] and leave the conversion to the point where overloading is resolved, but that's a much longer story. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31)

Thanks for your replies. In particular to Jon for the reference to the Haskell 98 standard and the comment about language design. If anyone has further references to Haskell 98 or Erlang, I'm still interested. Regarding cost, I do see the difference in factors (Integer - Int, and computable real - Double) as being relevant, but not necessarily a show-stopper. Regarding co-semidecidable equality, I'll just note that any numerical analyst knows that you're not allowed to compare for equality in Double either. Rationals or the real algebraic closure do have decidable equality but are, as far as I know, even more costly to compute with. Thanks, Jens