Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Int literals over "max unsigned 32bit" produce bad JS #1246

Open
rluiten opened this issue Jan 1, 2016 · 8 comments
Open

Int literals over "max unsigned 32bit" produce bad JS #1246

rluiten opened this issue Jan 1, 2016 · 8 comments
Labels

Comments

@rluiten
Copy link

rluiten commented Jan 1, 2016

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;
@evancz evancz added the bug label Feb 12, 2016
@evancz evancz changed the title Elm v0.16, Win7 - Int string literals over unsigned 32bit Int are being modified into js source. Int literals over "max unsigned 32bit" produce bad JS Feb 12, 2016
@lukewestby
Copy link
Member

Just bumping this as the issue still persists in 0.17.1

a =
    1000000000000000000000
var _user$project$Main$a = 3875820019684212736;

@lovasoa
Copy link

lovasoa commented Jan 24, 2017

On ubuntu 64bits, in elm-repl:

> 10000000000000000000000000000
4477988020393345000 : number

@lovasoa
Copy link

lovasoa commented Jan 24, 2017

and :

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

pdavidow added a commit to pdavidow/btree that referenced this issue Jun 8, 2017
`Arithmetic.isPrime (1000 ^ 1000)` HANGS THE SYSTEM
elm/compiler#1246
@norpan
Copy link

norpan commented Jul 6, 2017

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
Copy link

norpan commented Jul 6, 2017

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
Copy link

lovasoa commented Jul 6, 2017

Why not a simple Integer ?

@norpan
Copy link

norpan commented Jul 6, 2017

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

@lovasoa
Copy link

lovasoa commented Jul 6, 2017

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.

nmbrgts added a commit to nmbrgts/elm that referenced this issue Oct 26, 2017
The large Int literals in some of these tests result in errors (see elm/compiler#1246) that can't be resolved without editing the test file. Changing the Int literals to Floats is a simple and effective solution.
nmbrgts added a commit to nmbrgts/elm that referenced this issue Oct 26, 2017
The large Int literals in some of these tests result in errors (see elm/compiler#1246) that can only be resolved by editing the test file. Changing the Int literals to Floats solves the issue. I think it would be best to fix  it here even though it does make the exercise more interesting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants