Next: Installation, Previous: Supported platforms, Up: Introduction [Contents][Index]
Hoot is still in active development and its API should be considered unstable and subject to change in future releases. Hoot currently supports the R7RS-small Scheme specification, a bit of R6RS, along with a subset of Guile-specific functionality such as prompts. Maximum compatibility with Guile is a long-term goal.
To compile Scheme to Wasm, Hoot takes advantage of the features in the
Wasm 3.0 specification. The most important of these features are tail
calls and GC reference types. The return_call family of
instructions has made the implementation of Scheme’s tail recursive
procedure call semantics relatively straightforward. GC reference
type instructions allow for heap allocated objects (and immediates via
the i31 type) that are managed by the Wasm runtime. This
allows Hoot to take advantage of production garbage collectors already
present in web browsers, obviating the need to implement and ship a GC
which would be both inferior to the host’s and a major source of
binary bloat.
As of Wasm 3.0, there is no way to capture stack frames. This poses an issue for implementing Guile’s delimited continuations. Hoot works around this limitation by using its own explicit stack. A compiler pass known as “tailify” rewrites all calls to be tail calls and saves/restores values onto the explicitly managed stack. This strategy is effective but adds significant runtime overhead, in terms of both time and space. Fortunately, the stack switching proposal will bring true stack frame capture to all Wasm runtimes soon. Once NodeJS and all major browsers have shipped support for stack switching, Hoot can begin the migration process.
Another beneficial proposal for Hoot is the multi-byte array access proposal. If accepted, this proposal will allow Hoot to greatly improve the performance of bytevector operations and emit less code.
There’s an additional Wasm proposal that Hoot has been built on that has, unfortunately, not found its way into the core Wasm specification: stringref. We still emit stringref instructions as it is useful in the compilation pipeline but it is reduced to being an intermediate form. A lowering pass replaces stringref instructions with something resembling the JS string builtins proposal but with 8-bit code units rather than 16-bit and the unfortunate limitation that strings are copied at the Wasm/host boundary.
Next: Installation, Previous: Supported platforms, Up: Introduction [Contents][Index]