You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: