RFC: Introducing the Bigint

[mununki]

Propose the Bigint in JS as a built-in type.
mdn: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/BigInt

Background

BigInt is a new primitive that provides a way to represent whole numbers larger than 2^53, which is the largest number Javascript can reliably represent with the Number primitive. It is not introduced yet to ReScript yet.

Proposal

Literal

nativeint is actually locked in ReScript. I'd like to suggest using the 'n' suffix for the bigint literal.

1n

Operators

Basically mostly same to the integer operators.

// arithmetic
1n + 1n
1n - 1n
1n * 1n
1n / 1n
2n ** 54n

// neg
-1n

// comparisons
2n > 1n
1n < 2n
1n >= 1n
1n <= 1n
1n == 1n
1n === 1n
1n != 1n
1n !== 1n

[zth]

Looking great! But I don't think the arithmetic operators can overlap with the regular int ones...? cc @cristianoc

[cometkim]

may related with #6477 and https://forum.rescript-lang.org/t/new-operator-for-bigint-support/3922

[tsnobip]

Looking great! But I don't think the arithmetic operators can overlap with the regular int ones...? cc @cristianoc

Can't we just open the BigInt module for this?

[zth]

Can't we just open the BigInt module for this?

How do you mean?

[mununki]

Looking great! But I don't think the arithmetic operators can overlap with the regular int ones...? cc @cristianoc

Yes, we can define new operator for the bigint, we can talk about in this thread. At the same time, I'm going to try to implement to make it using same operator with int, wonder how it looks.

[mununki]

Can't we just open the BigInt module for this?

If I understand correctly, @tsnobip meant that Belt.Result.t<'a,b'> before it is moved to the predef.

[tsnobip]

I just meant that the regular + is defined for big ints in RescriptCore.BigInt module for example, so when you open BigInt, you can use the regular + for big ints, and of course you won't be able to use it for regular ints anymore.

We can also define a special syntax for the big int operators, like +! for example.

[mununki]

Similar to @cometkim suggestion, I'm wondering why the comparison operator only checks if the two arguments are the same type, and the arithmetic operator should be split between integer and float. Maybe it's for compiler efficiency, but why not just check if the two arguments are the same type like the comparison operator?

[CarlOlson]

I'm wondering why the comparison operator only checks if the two arguments are the same type, and the arithmetic operator should be split between integer and float.

Ocaml assigns types based on function usage. You need types assigned for certain optimizations. You couldn't have a compilation unit that exports a polymorphic function and expect it to work on BigInts, Floats, and Ints.

For example, compare the output of the two functions:

module Int = {
  external \"+": ('a, 'a) => 'a = "%addint"
  external \"-": ('a, 'a) => 'a = "%subint"
  external \"*": ('a, 'a) => 'a = "%mulint"
  external \"/": ('a, 'a) => 'a = "%divint"

  let add1 = (x) => x + (x / x)
}

module Float = {
  external \"+": ('a, 'a) => 'a = "%addfloat"
  external \"-": ('a, 'a) => 'a = "%subfloat"
  external \"*": ('a, 'a) => 'a = "%mulfloat"
  external \"/": ('a, 'a) => 'a = "%divfloat"

  let add1 = (x) => x + (x / x)
}

If you look at the source of polymorphic comparisons, it is much more complex. If you need performance, you should avoid using it.

[mununki]

@CarlOlson Yes, indeed. The typechecking logics are quite complex than I expect 😄
Actually, I changed the arithmetic operations to polymorphic for int and bigint for test. I haven't benchmarked it yet, but I'm sure there will be a downgrade in compilation performance, and I'll have to modify the type checker to not accept any types other than int, float, and bigint.

let d = 1 + 1
let e = 1n + 1n
let f = 1.0 + 1.0
let g = "a" + "a" // should be type error
let h =
  {
    () => 1
  }() + 1

[mununki]

I'm thinking it's a choice between adding another operator for bigint and changing the operators to a polymorphic type, what do you guys think?

[tsnobip]

You could actually even keep it for strings, so it's like JS.

But I wouldn't trade any performance for this! If it has an impact, then adding operators for big ints would feel natural.

[mununki]

You could actually even keep it for strings, so it's like JS.

I think the JS output maybe look okay, but looks weird in syntax layer. we have string concatenation ++ already.

[cometkim]

It's not that simple. It's what the rest of the world calls type classes (or extensions), and OCaml has been evaluating it for a decade (modular implicit).

What I proposed in #6477 is a much simpler solution and is how already done in F#

[cometkim]

I'm wondering why the comparison operator only checks if the two arguments are the same type, and the arithmetic operator should be split between integer and float.

This is absolutely necessary. The polymorphic + in JS actually differentiates int32 inside the engine. Thanks to ReScript's %addint, it is very friendly to JIT optimization. On the other hand, BigInt's + is not polymorphic. It will check the type early and throw a TypeError.