Compiler Architecture
ReScript's high level architecture:
Source Language | | (Reuse OCaml Parser) v Surface Syntax Tree | | (built-in Syntax tree transformation) v Surface Syntax Tree | | (Reuse OCaml Type checker) v Typedtree | | (Reuse OCaml pattern match compiler and erase types) | (Patches to pass more information down to Lambda ) | OCaml Lambda IR | | v Buckle Lambda IR ------------------+ | ^ | | | 6 Lambda Passes (lam_* files) | | Optimization/inlining/dead code elimination | \ | | \ --------------------------+ | | Self tail call elimination | Constant folding + propagation V JS IR (J.ml) ---------------------+ | ^ | | | 6 JS Passes (js_* files) | | Optimization/inlining/dead code elimination | \ | | \ -------------------------+ | | Smart printer includes scope analysis | V Javascript Code
Design Decisions
The design of ReScript follows several high-level principles. While those principles might change in the future, they are enforced today and can explain certain technical limitations BS has.
Lambda Representation
As pictured in the diagram above, ReScript is primarily based on the Lambda representation of the OCaml compiler. While this representation is quite rich, some information is lost from the upstream representation. The patch to the OCaml compiler tries to enrich this representation in a non-intrusive way (see next section).
Minimal Patch to the OCaml compiler
ReScript requires patches to the OCaml compiler. One of the main reasons is to enrich the Lambda representation so that the generated code is as nice as possible. A design goal is to keep those patches minimal and useful for the OCaml compiler in general so that they can later be integrated.
Soundness
ReScript preserves the soundness of the OCaml language. Assuming the FFI is correctly implemented, the type safety is preserved.
Minimal new symbol creation
In order to make the JavaScript generated code as close as possible to the original OCaml core we thrive to introduce as few new symbols as possible.