Compiler: Int literals over "max unsigned 32bit" produce bad JS

[rluiten]

I am on Window 7 64 bit running Elm v0.16.
Someone on google groups (Max) produced the expected results on his OsX El Capitan computer.

It appears Elm compiler can only read string literal integers up to size (2^31 - 1) and set them reliably into the output javascript.

I don't currently have any issues with it not liking bigger than signed 32 bit string literal integers.
What surprised me is that there is no error from the compiler when it processed them it just silently truncates or wraps the value.

I would personally like to see errors for any string literal that isn't the same value produced as literal in the javascript code.

Examples Elm.

a : Int
a = 324238402840
b : Int
b = 33324238402840
c : Int
c = 4294967296 -- 2^32
d : Int
d = 4294967295 -- 2^32 - 1
e : Int
e = 2147483648 -- 2^31
f : Int
f = 2147483647 -- 2^31 - 1

Example result in javascript.of above Elm

   var f = 2147483647;
   var e = -2147483648;
   var d = -1;
   var c = 0;
   var b = -412846824;
   var a = 2115855640;

[lukewestby]

Just bumping this as the issue still persists in 0.17.1

a =
    1000000000000000000000

var _user$project$Main$a = 3875820019684212736;

[lovasoa]

On ubuntu 64bits, in elm-repl:

> 10000000000000000000000000000
4477988020393345000 : number

[lovasoa]

and :

> round 1e10 --works
10000000000 : Int
> truncate 1e10 --fails
1410065408 : Int

[norpan]

I looked into this. It seems to be a problem already in the AST, as the data type looks like this:

data Literal
  = Chr Text
  | Str Text
  | IntNum Int
  | FloatNum Double
  | Boolean Bool
  | deriving (Eq, Ord)

Haskell only guarantees 2^29-1 for Int, so it should be changed to Int64, or Double (as javascript uses Doubles for numbers anyway).

[norpan]

The problem may also be fixed by using a 64-bit GHC to build the compiler, however, it should really work with a 32 bit version too.

[lovasoa]

Why not a simple Integer ?

[norpan]

Javascript only uses Doubles anyway so anything more than that is not needed

[lovasoa]

But anyway, everyone expects his constants to be found as-is in the generated javascript code. I think it costs nothing to use an Integer here.