Currying not optimized away any more about rescript-compiler HOT 8 CLOSED

I will make a new release tmr, now it should generate code like below:

console.log(pmap(function (x) {
            return x;
          }, [
            "a",
            "b"
          ])[0]);

Note that pmap is correct but not optimized (previously incorrect), the code is not optimized yet
Some optimizations we are going to do(high priorities):

1. we only need test the arity of f for once, in most cases it will be a fast path
2. when it does get inlined, the curry will be gone, but note that whether it will be inlined or not depends on the huristics of the compiler, in ocaml 4.03, there is an attribute [@@inline always], we can make use of it in the future

Type based optimization(low priorities)

1. by making use of the typing environment, we know that f return type is not a function, so it can not be partial applied

from rescript-compiler.

Note that pmap is correct but not optimized (previously incorrect)

I see, I almost imagined it was incorrect.

we only need test the arity of f for once, in most cases it will be a fast path

Does this mean it will only be evaluated once per program run?

when it does get inlined, the curry will be gone

Is inlining currently not working, or do you know why it doesn't get inlined in this trivial example?

from rescript-compiler.

Can you post both ml and mli so I can see why it's not inlined, note mli will affect the inline behavior

from rescript-compiler.

No .mli file. It would be good if the function could be inlined here in order to eliminate Caml_curry.app1

type point = {
  y: int;
  x: int;
}
let pmap fn p = { x = fn p.x; y = fn p.y }
let use_pmap x p = pmap (fun y -> x + y) p

from rescript-compiler.

hi @copy, now we have native support for uncurry, so you can make a callback uncurry, so it will be always optimized

type point = {
  y: int;
  x: int;
}
let pmap fn p = { x = fn #@ p.x; y = fn #@ p.y }
let use_pmap x p = pmap (fun%uncurry y -> x + y) p

#@ is the curried function application, %uncurry is the curried function definition

basically

let f = fun %uncurry (x,y) -> x + y

val f : int * int -> int [@uncurry]

let a = f #@ (1,2)

I will document it next week, let me know what you think. We will provide ppx support for both native backend and js backend so your code should work on both backend.

In general, for callback, the optimization relies on inlining which is hard to predict, I think using uncurried callback might be better performance wise

from rescript-compiler.

Cool, that's useful for my use-case. Is the annotation only a hint for optimization or does it create a special type?

In general, for callback, the optimization relies on inlining which is hard to predict, I think using uncurried callback might be better performance wise

I agree, although inlining will be more controllable with the new annotations, and it's easier if you only need to annotate the callee. Is 4.03 support planned in the near future?

from rescript-compiler.

@copy yes, it will create a special type under JS backend, the rewrite rules are quite simple (as below)

('a0 * 'a1 * 'result ) Js.fn <==========> 'a0 * 'a -> 'result [@uncurry]

In general, we plan to target the bug fix release of OCaml compiler

from rescript-compiler.

see the docs
https://bloomberg.github.io/bucklescript/Curry-and-Uncurry-functions.html

from rescript-compiler.