PoC: Unified infix operators

[cometkim]

Trying to solve #6477, but without implicit open

Rationale

As explained in #6477, we have the "infix explosion" problem. To relax it, I added some specialization to both type inference and primitive inspired by F#

https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/symbol-and-operator-reference/arithmetic-operators#operators-and-type-inference

The idea is, to extend the type inference rules for infix (and some unary) operations defined in Pervasives to specialize them for predefined types but fall back to int if they cannot be inferred or the types of the left-hand and right-hand are different.

let t1 = 1 + 2     // => external \"+": (int, int) => int = "%addint"
let t2 = 1. + 2.   // => external \"+": (float, float) => float = "%addfloat" 
let t3 = "1" + "2" // => external \"+": (string, string) => string = "%string_concat"
let t4 = 1n + 2n   // => external \"+": (bigint, bigint) => bigint = "%addbigint"

let fn1 = (a, b) => a + b        // => external \"+": (int, int) => int = "%addint"
let fn2 = (a: float, b) => a + b // => external \"+": (float, float) => float = "%addfloat" 
let fn3 = (a, b: float) => a + b // => external \"+": (float, float) => float = "%addfloat" 

let inv1 = (a: int, b: float) => a + b  // => external \"+": (int, int) => int = "%addint"
//                                   ^ error: cannot apply float here, expected int

This doesn't make a breaking change, since the existing operations are defined on int already.

However, we can introduce them as unified operators for the new codebase. They are still safe, as they are always specialized and not polymorphic.

Specialized operators:

Op	Primitive	supported types
\"~-"	%neg	int, float, bigint
\"~+"	%identity	int, float, bigint
\"+"	%add	int, float , bigint, string
\"-"	%sub	int, float, bigint
\"*"	%mul	int, float, bigint
\"/"	%div	int, float, bigint
mod	%mod	int, float, bigint
\"**"	%pow	int, float, bigint
abs	%abs	int, float, bigint
land	%land	int, bigint
lor	%lor	int, bigint
lxor	%lxor	int, bigint
lnot	%lnot	int, bigint
lsl	%lsl	int, bigint
lsr	%lsr	int
asr	%asr	int, bigint

Side note

This PR doesn't attempt to add custom ops or polymorphic ops, but that's the specialized custom ops already possible by opening a module.

Polymorphic ops should deprecated. they are unpredictable and inefficient, as explained in #7031. So in future versions, comparison will have consistent behavior with this. It will be a breaking change, but we don't have a better alternative yet.

[cometkim]

Checking rhs type in inference adds quite a bit of complexity. I wonder if there are any use cases for this. If not, it makes sense to consider checking only lhs type.

[zth]

@cometkim you waiting on anything from any of us on this one?

[cometkim]

@cometkim you waiting on anything from any of us on this one?

No, I just took a break from coding over the Korean holidays.

[zth]

@cometkim you waiting on anything from any of us on this one?

No, I just took a break from coding over the Korean holidays.

Enjoy your holidays!