zapashcanon 7 months ago
parent
commit
eef9e14948
Signed by: zapashcanon GPG Key ID: 8981C3C62D1D28F1
  1. 14
      wasocaml.tex

14
wasocaml.tex

@ -57,7 +57,7 @@
In this presentation, we explore the compilation of OCaml to WebAssembly (Wasm).
The limitations of JavaScript as the default language of the web led to the development of Wasm, a secure and predictable-performance modular language.
However, compiling garbage-collected languages to Wasm presents challenges, including the need to compile or re-implement the runtime.
Some Wasm extensions are developped by the Wasm working groups to ease the compilation of garbage-collected languages.
Some Wasm extensions are developed by the Wasm working groups to facilitate the compilation of garbage-collected languages.
We present Wasocaml, an OCaml to Wasm-GC compiler.
Different strategies to map the OCaml value representation technique to WasmGC and our compilation scheme are detailed.
Finally, we describe how we plan to handle the C/JavaScript FFIs and effects handlers within Wasocaml.
@ -137,12 +137,12 @@ powerful enough to do that. Instead, the decision was to have a simple
type system, but to rely on dynamic cast to fill the gaps, and guarantee that
those casts are efficient.
There is a subtyping relation that controls which casts are
There is a sub-typing relation that controls which casts are
allowed. Some types are predefined by Wasm: \mintinline{wast}{anyref},
\mintinline{wast}{eqref}, \mintinline{wast}{externref},
\mintinline{wast}{funcref} and \mintinline{wast}{i31ref}.
Others are user defined: array and struct. There is a structural
subtyping relation between user types. Upcasts are implicit, downcasts
sub-typing relation between user types. Upcasts are implicit, downcasts
are explicit and incorrect ones lead to runtime errors.
It is possible to dynamically test for type compatibility.
@ -154,7 +154,7 @@ It is possible to dynamically test for type compatibility.
\paragraph{Contribution to the proposals.}
The general rule for the Wasm comittee is to only include features
The general rule for the Wasm committee is to only include features
with a demonstrated use case. As there are currently very few
compilers targeting the GC-proposal, some features were lacking
conclusive evidence of their usefulness. An example is the \mintinline{wast}{i31ref}
@ -173,7 +173,7 @@ It helped in convincing the working group to keep \mintinline{wast}{i31ref} in t
Another serious limitation of Wasm1 is the absence of an exception
mechanism. This is not a problem for compiling either C or Rust, but
C++ does require them. It is of course possible to encode exception, but
this has a significative runtime cost and limits the interactions
this has a significant runtime cost and limits the interactions
with JavaScript (that has exceptions).
\subsubsection{Tail Calls}
@ -440,7 +440,7 @@ Hence, we have to duplicate this in Wasocaml. Compiling this
requires some kind of structural subtyping on closures such that,
closures for functions of arity one are supertypes of all the other
closures. Thankfully there are easy encodings for that in Wasm.
% TODO: explicit closures subtyping depending on the arity and the encoding in wasm
% TODO: explicit closures sub-typing depending on the arity and the encoding in wasm
%% TODO example ml partial apply
@ -518,7 +518,7 @@ We are able to compile an OCaml implementation of the
Knuth-Bendix algorithm~\cite{KB83}.
For now, it leads to runtime errors.
We have not been able to reproduce the error on a smaller case.
It is unclear wether our generated Wasm is incorrect or if we are
It is unclear whether our generated Wasm is incorrect or if we are
hitting a bug in the experimental V8 support for all Wasm extensions
we require.

Loading…
Cancel
Save