[Haskell-cafe] Int is broken [Was: Different answers on different machines]
carter.schonwald at gmail.com
Mon Jun 3 08:58:59 CEST 2013
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
Additionally, theres work in progress to support "branchless" Bool
operations in GHC by having Bool be represented internally With 0,1 valued
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
On Sun, Jun 2, 2013 at 6:42 PM, Dan Doel <dan.doel at gmail.com> wrote:
> There is a package that implements an Int that throws an exception on
> 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
> On Sun, Jun 2, 2013 at 5:02 PM, Tommy Thorn <tt1729 at yahoo.com> wrote:
>> On Jun 2, 2013, at 12:52 , Henry Laxen <nadine.and.henry at pobox.com>
>> > Yes, that was it. The dell was a 32 bit system, and the desktop a 64.
>> > changed everything from Int to Integer, and now both agree. Thanks for
>> > 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.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe