Schedule

For several years now, Robur has been working to develop unikernels using the MirageOS framework, which it maintains on a daily basis. However, the technical choices that shaped the workflow have shown their limitations in terms of technology, user experience, and maintenance. As a result, for the past two years, Robur has been exploring a new approach to developing unikernels that addresses both technical challenges (static linking of an OCaml binary and cross-compilation of C stubs) and improvements to the user experience (libraries and APIs, integration with an existing ecosystem, and long-term maintainability).

This talk will focus on this new workflow through practical examples, explaining its objectives (to “democratize” unikernel development for everyone) as well as a retrospective on past limitations related to the MirageOS framework.

Many large OCaml applications do not consist of OCaml code alone. They depend on native C and C++ libraries accessed through the OCaml foreign function interface (FFI), where bindings often manipulate OCaml values directly and rely on the runtime's data representation and memory layout. This coupling is what makes such applications hard to bring to the browser. How to port them together with their entire native dependency stack remains largely unexplored.

OCaml programs run either as machine code from the native compiler or as bytecode interpreted by the OCaml runtime. Neither runs in a browser, so the existing browser backends translate the program ahead of time, to JavaScript (js_of_ocaml) or to WebAssembly (wasm_of_ocaml). All of them compile the OCaml code alone and leave the C and C++ behind, the FFI included.

Rather than translating the program, we compile the OCaml runtime itself, together with the complete native dependency stack, to WebAssembly with Emscripten as a single statically linked module, and interpret the unmodified bytecode on top of it. Linking the runtime supplies the primitives the FFI stubs call. The bytecode's external calls are bound through a static primitive table, the mechanism behind OCaml's statically linked (custom) executables, instead of the dynamic loading the runtime performs at startup. Neither the hand-written FFI code nor the CamlIDL-generated stubs are modified.

This paper reports on our experience doing so for MOPSA, a static analyzer that combines OCaml with LLVM/Clang, GMP, MPFR, Apron, and CamlIDL-generated bindings, running it entirely inside a web browser.

Cap.ml is a small library providing capability types to use in a disciplined manner the UNIX system calls behind standard library functions such as Sys.command, Unix.fork, or even Stdlib.open_in. When combined with the use of the Semgrep tool and capability rules, it can offer stronger guarantees on a codebase.

LexiFi has maintained a fork of OCaml for 25 years, extending vanilla OCaml with support for "runtime types". Recently there has been renewed interest in this feature. To help inform the public discussion, we propose a presentation giving an overview of this feature as it exists inside LexiFi.

Since OCaml 4.14 and the implementation of Tail Modulo Constructor [1, 3] in OCaml, the compiler is able to manipulate Destinations and to transform functions in Destination Passing Style. Destinations corresponds roughly to C-style output-arguments and are often implemented directly as write-once pointers. They are very useful to build complex data-structure piece-wise, by leaving holes in the structure that will be filled by later function calls.

Such destinations can be used to implement interesting syntactic transformation, such as Tail Modulo Async/Await, or language-integrated memoisation. In a recent RFC, we thus argue for exposing destinations as first class object via a new compiler-supported library. This talk will present our proposal along with several use-cases and debate some implementation choices.

Slipshow is a presentation tool, that includes a markdown compiler, a presentation engine running in the browser, an LSP server with a preview server, a stroke editor akin to a video editor, and many other features. In this experience report, we'll see how it evolved from a single Javascript file to what it is now, thanks to the OCaml language, its compiler, tooling, and a high quality library ecosystem.

An interactive editing environment for a programming language closely resembles the front-end of its compiler. Merlin, the recommended Language Server for OCaml[1], therefore embeds a modified copy of the OCaml front-end. Unlike a compiler, which analyzes complete and syntactically valid programs, an editor continuously operates on incomplete programs that are temporarily inconsistent or ill-typed. To bridge this gap, Merlin relies on two recovery mechanisms. Parsing Recovery synthesizes AST nodes that allow parsing to continue after syntax errors, while Typing Recovery synthesizes typed AST nodes that allow type checking to continue after type errors. These mechanisms are currently implemented as a collection of patches maintained on top of each supported version of the OCaml type-checker.

This presentation describes the work that led to the integration of the Typing Recovery mechanism directly into the OCaml type-checker, in order to reduce divergence between Merlin and the compiler, simplify code maintenance, and align their evolution cycles.

OxCaml provides stack allocation, unboxed types and layouts, SIMD vector types, and bit-manipulation intrinsics. These features promise more explicit control over allocation, representation, and SIMD code than OCaml programmers usually have. In our parser, that control was valuable, but the result was not C++ in OCaml syntax; it was a faster OCaml program with OCaml-shaped tradeoffs.

This talk describes lessons learned while implementing a simdjson-style JSON parser in OxCaml. The resulting parser is over 5x faster than existing OCaml parsers such as Yojson and Jsont, while still exposing a conventional Json.t API that users can pattern match on. In our benchmarks, the convenient tree API reaches 76% of RapidJSON's throughput, though it remains roughly 4x slower than the C++ simdjson implementation; a lower-level tape representation edges past RapidJSON and reaches 38% of simdjson throughput.

We report which features worked directly, where integration required extra care, and which language and library extensions would help downstream users build performance-critical OCaml applications.

The OCaml type system, and its module system in particular, is eminently malleable. One of the consequences of this flexibility is that the same entities can often be referred to by multiple names. Short-paths is the feature that tries to find the shortest path before printing something. Two implementations of short-paths already exist: one in the compiler and one in Merlin. Both are unsatisfying in different ways and in this talk we describe a new blank-slate implementation of that should surpass them in correctness and performances.

In this talk, we discuss our efforts to implement a new benchmarking system for OCaml, with the aim of building a successor to the Sandmark suite as a comprehensive community-facing OCaml performance tracking system. We take inspiration from the consolidated DaCapo benchmark framework for Java, collecting macro-benchmarks from a diverse set of OCaml real-world applications. In the talk, we explain why this benchmarking system is a crucial part of keeping track of performance regressions, how our benchmarking setup is structured, and some preliminary outcomes from our initial prototype. We end the talk by presenting the next steps for our project.

OCaml's centrally-generated documentation site, ocaml.org, serves API documentation for almost every opam package, complete with rendered source, type-aware search and cross-package links. Locally, however, documentation remains second class: building the docs for a project and its dependencies requires slow, non-incremental tooling that must rediscover information the build system already had. We propose a simple change with far-reaching consequences: each package should build and install its own odoc files, just as it installs its compiled artifacts today. This removes the discovery problem that complicates every existing documentation driver, and makes first-class experiences straightforward to build: documentation available on install, fast incremental rebuilds with actionable errors in the IDE, CI checks for broken docs, and local search. We survey the current documentation pipeline, describe the challenges facing per-package build rules, and outline a migration path, including an opam-hook-based emulation that is usable today.