-
Notifications
You must be signed in to change notification settings - Fork 9
Description
We should investigate whether we can take the Flambda2 intermediate code as input, beside bytecode.
This seems complicated with js_of_ocaml. Indeed, Flambda2 has explicit closures which may be accessed from outside the function body, due to inlining. But maybe it is possible to eliminate most of these closures, turning them into regular JavaScript functions. This should not be a problem with wasm_of_ocaml, which emits explicit closures at the end anyway. But can we then avoid too much code duplication, or having wasm_of_ocaml diverge from js_of_ocaml?
There will be some issues with unboxed types. We currently use arrays for heap-allocated OCaml values. If we always knew the exact shape of the values when accessing them, we may be able to use structs instead. But I’m not sure this information is still available.