Elm format changes large integer literals

[harrysarson]

The following elm code:

module Main exposing (toWrite)


largeInt: Int
largeInt=
    1000000000000000000000

is is changed by elm-format as such:

--- a/Main.elm
+++ b/Main.elm
@@ -3,4 +3,4 @@ module Main exposing (toWrite)
 
 toWrite : String
 toWrite =
-    String.fromInt 1000000000000000000000
+    String.fromInt 3875820019684212736

The code is malformed anyway due to elm/compiler#1246 but this will become a problem as and when the elm compiler generates correct code for this. The underlying issue is the AST uses too small an integer datatype.

[avh4]

Are you using the Windows binaries (which are compiled with 32-bit haskell), or the Mac/Linux ones?

[harrysarson]

Yes windows!

[avh4]

Ah, okay, in that case I suspect it might be fixed if you were to compile elm-format from source with a 64-bit haskell installation.

I've only been releasing 32-bit windows binaries because it seemed to work and caused the least confusion, but I might try taking a look at building 64-bit also.

[avh4]

Hmm... though it looks like this is reproducible on linux too 🤔

[harrysarson]

Presumably the root cause is the same here and over at the elm compiler?

[harrysarson]

The issue is that this number (1000000000000000000000 or 0x36_35C9ADC5_DEA00000) requires more than 64 bits to represent.

Elm format changes it to 3875820019684212736 or 0x35C9ADC5_DEA00000, truncating it to the least significant 64 bits.

Whilst elm format may well not want to support such big numbers, it should at the least exit with an error when such a literal is encountered.

[harrysarson]

What if elm-format did not try to encode literals as Int's in the AST but kept all literals as strings? This way there would be no encoding issues.

[basile-henry]

Integer (big num) is pretty standard in Haskell. I think using it instead of Int is the simplest change. If you encode it as String you run the risk of allowing non integers to be represented.

[avh4]

I think this is actually correct for now, as elm-format shows the user how elm-compiler will interpret the code. When elm-compiler is changed, this should be revisited in elm-format.

[harrysarson]

I would prefer to see elm-format raising a parsing issue rather than silently corrupting* source code files.

Alternatively, if elm-format left big integer literals as they are there would be scope for tools like elm-review to start warning about them.

* I worry that corrupting is a subjective and also possibly inflammatory term. I use it only to hint at my underlying concern with marking this at wont-fix for now. I do definitely understand your rational for leaving this as it but I would like to register gentle disagreement. Please do not think I am notnhugely appreciative of this very good and useful tool!