ppx: qualify usages of stdlib infix operators

[jchavarri]

No description provided.

[davesnx]

Much needed PR

[andreypopp]

for the cases where type is already known — I'd use type specific equality operator — e.g. Stdlib.Int.equal for int and so on

By the way not should also be qualified.

[jchavarri]

for the cases where type is already known — I'd use type specific equality operator — e.g. Stdlib.Int.equal for int and so on

I'm not sure, this will be adding more runtime without a lot of benefits, see example in playground:

let foo (a: string) (b: string) = Js.log (a = b)
let foo2 (a: string) (b: string) = Js.log (String.equal a b)

produces:

function foo(a, b) {
  console.log(a === b);
}

function foo2(a, b) {
  console.log(Stdlib__String.equal(a, b));
}

[andreypopp]

I'm not sure, this will be adding more runtime without a lot of benefits, see example in playground

wow, didn't know that, then it's good as it is, thank you!

[jchavarri]

By the way not should also be qualified.

Done in d2f8497.

[anmonteiro]

for the cases where type is already known — I'd use type specific equality operator — e.g. Stdlib.Int.equal for int and so on

I'm not sure, this will be adding more runtime without a lot of benefits, see example in playground:

let foo (a: string) (b: string) = Js.log (a = b)
let foo2 (a: string) (b: string) = Js.log (String.equal a b)

produces:

function foo(a, b) {
  console.log(a === b);
}

function foo2(a, b) {
  console.log(Stdlib__String.equal(a, b));
}

oh interesting. I think this is because String.equal is a external .. in the .ml but a val in the .mli.

[andreypopp]

oh interesting. I think this is because String.equal is an external .. in the .ml but a val in the .mli.

@anmonteiro should we fix this?

[anmonteiro]

oh interesting. I think this is because String.equal is an external .. in the .ml but a val in the .mli.

@anmonteiro should we fix this?

I think it's a good idea -- I'll play with it