Re: [Haskell-cafe] Int is broken [Was: Different answers on different machines]

Indeed, as Dan says, theres the safeint library and the Integer type. If the Int type had either of these semantics by default, many many performance sensitive libraries would suddenly have substantially less compelling performance. Every single operation that was branchless before would have a branch *every* operation..... this would be BAD. I'm actually quite happy with (ab)using Int as just a sequence of bits that sometimes i treat as a number, and sometimes i treat as a bitvector. In fact thats actually most of my work these days. GHC generates VERY nice code for Ints and Words, similar to what i'd expect to be Generated by a decent C compiler when not explicitly using SIMD operations. This is a good thing! Additionally, theres work in progress to support "branchless" Bool operations in GHC by having Bool be represented internally With 0,1 valued Ints, http://hackage.haskell.org/trac/ghc/wiki/PrimBool point being: its easy to have the safety with SafeInt, or Using Integer, and fast inner loops can't have branches, and that actually matters in many applications. cheers -Carter On Sun, Jun 2, 2013 at 6:42 PM, Dan Doel wrote:

There is a package that implements an Int that throws an exception on overflow:

http://hackage.haskell.org/package/safeint

Since Int's existence is pretty much all about trading for performance, I wouldn't recommend holding your breath on the above becoming the default.

If you want things to work like Scheme, that's exactly what Integer is (in GHC, anyhow). And Integer is what you get by default(ing) unless you use something else that is specifically defined to use Int, or specify it yourself.

On Sun, Jun 2, 2013 at 5:02 PM, Tommy Thorn wrote:

...

On Jun 2, 2013, at 12:52 , Henry Laxen wrote:

...

Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I changed everything from Int to Integer, and now both agree. Thanks for the pointer.

Isn't that just terrible? I hate the fact that Haskell was defined to neither trap the overflow or just treat everything as Integer [like Scheme]. A sacrifice of program safety in the name of efficiency.

I disagree with this choice and posit that a clever implementation can minimize the cost of the overflow checking in most relevant cases.

I wish this fatal flaw would be reconsidered for the next major revision.

Tommy

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe