Int/Float ambiguity passing from JS runtime to Wasm app

[brian-carroll]

When a number is passed from the JS runtime into the Wasm app (wrapped in a message), there is no reliable way to know whether it is an Int or a Float.

There are a few reasons for this

• There is no difference in JS semantics between the Elm Int 1 and the Elm Float 1.0.
• The compiler discards type information in the AST, long before it gets to the code generation stage

Fixing this bug is a hard requirement for correctness. Elm in Wasm is unusable in real apps until this is fixed.

The issue only occurs for messages passing from the JS runtime into the Wasm app. Not the other way around, and not inside the app code itself.

As far as I can see, there are two possible approaches:

1. Get enough type information to the code generator so that it knows which messages take Ints and which take Floats. Use this info to configure the JS wrapper around the Wasm module. This would involve changing several of the AST types and fixing all resulting Haskell errors.

2. Create a hardcoded list in the compiler of all the kernel functions that return either Int or Float values as the result of a Cmd or Task. (There probably aren't really that many!) Use this info to configure the JS wrapper around the Wasm module. This is definitely less elegant/satisfactory, but could be much less work.

[HuwCampbell]

Don't know if you're still interested in this, but I've written a change to the type check pass so it returns a canonical module with the expected type as its annotation instead of the location annotation.

This comes along for the ride when generating the constaints, and, as the type variables are mvars, gets zonked on solve as well.

It's not amazingly useful right now, as polymorphic functions like

add : number -> number
add a b = a + b

still don't say anything interesting; but it might help in your use case, or if one wants to further elaborate the number system to be more 'type class' based, and have a number dictionary dragged along with functions.

[brian-carroll]

Very cool!
I haven't done anything on this project for ages. But that mod sounds cool.

[HuwCampbell]

I've pushed the code here:

https://github.com/HuwCampbell/elm-compiler/tree/topic/type-annotated

I did originally implement on top of your branch, but I've just cherry-picked it back to the main-line. It's pretty stand alone anyway (and not super tested, but hey, the compiler has no tests anyway).

[HuwCampbell]

What I'm most interested in right now running user's elm code with a Haskell runtime safely on the backend so they can write domain specific business logic with it.

I really don't want to hook in a node process which leaves 2 realistic options:

• Linking C
• Writing a Haskell interpreter (I think @supermario did this for Lamdera which is cool).

But I think sorting out numbers will be important no matter which way it goes.