Target-specific code

[OlivierNicole]

Note: This PR depends on #1649 and #1654 and is based on top of them. The proposed feature is contained only in the last commit. edit: These PRs have been merged.

This PR contains @vouillon's work to have two distinct targets: Javascript and WebAssembly.

Dune support for the new Wasm backend has been proposed at ocaml/dune#10695.

This is part of a series of PRs intending to reduce the diff between js_of_ocaml and wasm_of_ocaml (see ocaml-wasm/wasm_of_ocaml#47).

[hhugo]

Turning into a draft until underlying PRs are merged

[hhugo]

@OlivierNicole, can you rebase, fix and undraft this PR

[OlivierNicole]

@OlivierNicole, can you rebase, fix and undraft this PR

Done.

[hhugo]

Do we really need to pass target around ? It creates a lot of noise for few uses only. It could be turned into an global config like use_js_string or effect. Alternatively, we could move all configs into a single config value and pass it around explicitly.

[OlivierNicole]

What I like about passing target around is that it makes it explicit in the type of functions that they depend on the target, and which backends they support.

The readability does not seem too much impaired to me, but it’s not a strong opinion, if there’s opposition to it I’m OK with a global config parameter, since it’s not a value that is expected to change during a run.

[hhugo]

Looking at the diff, I find it hard to extract where the behavior depend on the target because there are so many targets passed around. I like that values are explicitly passed but I don't see a reason to treat backends differently from other "config" (e.g. use_js_string).

• I would use a global to flag for now, making the diff much smaller.
• We could revisit the global state logic later and try to pass some config around.

[TyOverby]

Wouldn’t a global flag make it harder to use the jsoo compiler as a library, which could be invoked many times with different targets?

[TyOverby]

For example, an online ocaml repl, or a “godbolt explorer” output visualizer

[hhugo]

Wouldn’t a global flag make it harder to use the jsoo compiler as a library, which could be invoked many times with different targets?

Sure, but we already have that issue with other flags, in particular, effects.

[OlivierNicole]

• I would use a global to flag for now, making the diff much smaller.

Done.

[hhugo]

@OlivierNicole, the CI is unhappy, and the diff has extra lines because of formatting. Can you run dune fmt ?

[OlivierNicole]

There was a subtyping relation not being automatically used under 4.12. The CI should be happy now.

[hhugo]

What's the semantics of nativeInt with the wasm backend?

[OlivierNicole]

They’re on 32 bits.

[hhugo]

Then we should use | NativeInt of Int32.t

[OlivierNicole]

Done. (Edit: and well spotted!)

[hhugo]

@OlivierNicole, @vouillon, I'm tempted to introduce a dedicated type & module for target int. What do you think ?
See #1693

[OlivierNicole]

Is the idea to have Targetint.t be an int31 in Wasm and int32 in JavaScript?

Sure, it sounds better, but IMO this looks like an improvement over the present PR that could be merged separately.

[vouillon]

That's a good idea, indeed.

[hhugo]

@OlivierNicole @vouillon I've rebased and adapted #1693.

[OlivierNicole]

Thank you for the exceptional review work.

[hhugo]

@OlivierNicole, what's the next step for ocaml-wasm/wasm_of_ocaml#47

[OlivierNicole]

I am in the process of merging the JSOO master into WSOO cleanly. Once that is done, my hope is to merge WSOO main into this repo as soon as possible, to avoid a new divergence and the amount of work involved in resorbing it. But that last step is blocked on ocaml/dune#10695.