Rescript-compiler: Provide Js.Number module?

[chenglou]

Any objection?

[bobzhang]

looks good to me, should be Js.Float? http://bloomberg.github.io/bucklescript/api/Js.Float.html

[chenglou]

Where would Number.parseInt go?

[bobzhang]

parseInt still returns a float

parseInt('9007199254740991')
9007199254740991

Note we can have another module, i.e, Js.Int32 to wrap such function

[gabrielperales]

Hi!, I'm learning reasonml and I'm trying to parse a string to an integer. My approach right now is:

let parseint: string => int = [%raw {| x => parseInt(x, 10) |}];

But I would like to know if there is any other better way to do it. I found that there is a Js.Float.fromString but I couldn't find a Js.Int.fromString

Thank you.

[OvermindDL1]

@gabrielperales If you are parsing at base 10, why not just use OCaml standard calls for that?

int_of_string "327819231"

I don't see the point in duplicating functionality, especially as that just makes code so so much harder to be able to compile it to native...

[gabrielperales]

@OvermindDL1 yep, I didn't see that function on the reasonml documentation and neither on the bucklescript one

[OvermindDL1]

@OvermindDL1 yep, I didn't see that function on the reasonml documentation and neither on the bucklescript one

That is because it is bog-standard-built-in-ocaml, should check the ocaml docs first and foremost before anything in bucklescript or reasonml as those just add to ocaml. ^.^

[abdullahibnnadjo]

@gabrielperales Hi, note that using built-in OCaml functions will (in some cases) add quite some code to your JavaScript bundle.
Since OCaml and JavaScript overlap in number of ways, some functions will be directly translated to JS (e.g. print_endline will simply become console.log), but it's not always the case, as int_of_string which will need: https://github.com/BuckleScript/bucklescript/blob/5860cdee318f3de08784badff545b32123380195/lib/js/caml_format.js#L100

Also, note that int_of_string don't work exactly like parseInt:

• parseInt will parse a number even if it's followed by other characters afterwards (different from 0-9) in the given string whereas int_of_string will fail
• On failure, parseInt will return NaN whereas int_of_string will throw an exception

As parseInt returns either a number or NaN, it needs to be wrapped to be used safely (check the NaN and check if the number is not too high or too low to fit in a 32-bit integer).
You can see both compared here on the playground.

It's up to you then to choose which one fits your needs.

[OvermindDL1]

will (in some cases) add quite some code to your JavaScript bundle.

That sounds like the translator should be specialized for certain functions then, not ignored. ;-)

After all, what if you have a hundred+ calls to JS-specific things in your library, then you want to use it in a native code (say for server side generation, or whatever), well that is suddenly a horror surrounding the JS'isms. ;-)

In addition, wasm support is now pretty standard, what if you want to compile it to wasm then (which OCaml can do as bytecode currently, and via llvm in not too long, maybe even a pure backend soon I'd fully expect), the JS'isms have messed up that too.

[abdullahibnnadjo]

@OvermindDL1 yeah sure. Even for test and mocking purposes. I think a good approch is to take advantage of OCaml modules to wrap any platform specific code, so changing the implementation details of those through the entire codebase is just a matter of changing one line in a config file (or just simply conditionnal compilation)