The OCaml Planet RSS

On 16 December 2000, a young @dra1 stepped out on to the stage of St Martin-in-the-Fields making what would be the first of many performances of Johann Sebastian Bach’s great Mass in B minor. On 16 November last year, just under 25 years later, a slightly greyer @dra27 stepped out on the stage of King’s Hall at Newcastle University for what, for now at least2, would be his last performance of this great work3. As I write this in the 9 hour window of unemployment between finishing at the University of Cambridge and Tarides and commuting down to 2½ Devonshire Square to start at Jane Street, it’s a new year and a change of course. the “27” wouldn’t be allocated until the next October ↩ never say never… ↩ I’ve never recorded the work, although I recorded Ach, bleibe doch from Himmelfahrtsoratorium BWV 11 with Musik Podium Stuttgart ten years ago, which is one of the source arias for the famous Agnus Dei of the mass ↩

The spring-cleaning continues! When I originally prototyped Relocatable OCaml, it was during the OCaml 4.13 development cycle. The focus for the work originally was always about multiple versions of the compiler co-existing without interfering with each other, so even the early prototypes were done on both OCaml 4.12 and OCaml 4.13. In fact, I see that in this talk, I even demo’d it on both versions. My intention from the start had always been to be able to provide either backports or re-releases of older compilers, on the basis that it would be tedious to have only the latest releases of OCaml supporting the various fixes, given that the failing CI systems which had motivated the project would continue to test older versions for several/many years after completion. In 2021, OCaml 4.08 (from June 2019) was still a recent memory. From a technical perspective, OCaml 4.08 was a very important release. It’s the first version of OCaml with a reliably namespaced Standard Library (the Stdlib module, though introduced in 4.07, had various issues with shadowing modules which weren’t completely addressed until 4.08). For my work, it was the version where we switched the configuration system to autoconf, and thus introduced a configuration system for the Windows ports. It provided a natural baseline in 2022 for the backports, and thus the workshop demonstration I gave in Ljubljana featured Windows and Linux for OCaml 4.08-4.14 as well as preview of OCaml 5.0.

As we settle into 2026, I have been doing a little early spring-cleaning. A few years ago, we had a slightly chaotic time in opam-repository over what should have been a migration from gforge.inria.fr to a new GitLab instance. Unfortunately, some release archives effectively disappeared from official locations, and although the content was available elsewhere, the precise archives weren’t generally available, which is a problem for the checksums in opam files. We’ve had similar problems with GitHub in the past. As a ‘temporary solution’, @avsm created ocaml/opam-source-archives to house copies of these archives (I think it’s a somewhat prescient sha for that first commit!). As is so often the case with temporary solutions, it’s grown somewhat. Rather against my personal better judgement, the repo got used to house files which used to be shipped as part of ocaml/opam-repository. Removing the files from the repository was a good change, because they were always being shipped as part of opam update, but unfortunately moving them to an “archive” repository has made it rather too tempting to add new files, making an archive repository a primary source.

As I was very happy to announce on Discuss on 12 December, OCaml is Relocatable! Today, the final piece of the puzzle was merged, which is the necessary support to allow opam to take advantage of all this to be able to clone switches instead of recompiling them. Before this, you could rename a local switch, for example, but opam would still be compiling them from scratch. The fruits of this continue to be available through my opam-repository fork, as announced in September, and will be available out-of-the-box for the first alpha release of OCaml 5.5 early next year.

Someone was kind enough a few weeks ago to comment on Hacker News that “Opam on Windows is a masterpiece of engineering”. There’s certainly a lot which has to go on under the hood to create what I believe is the necessary baseline experience. Unfortunately, it doesn’t always work out.

I spent last week at ICFP 2025. A nice (if exhausting!) week, as ever. Amusingly, the most reflections were actually sparked by Yaron’s talk which was right at the end (you can see the talk itself on YouTube).

Continuing the previous foray into file descriptors, and trying to remove Obj.magic both from ocaml-uring’s code itself, and from the recommended way for using it.

There was a flurry of activity on ocaml-multicore/ocaml-uring this month leading to a release (ocaml/opam-repository#28604). ocaml-uring provides bindings to the Linux’s io_uring, which allows batching various syscalls to the kernel for it to execute out-of-order, and in parallel. Its principal use at the moment is for the high-performance Linux backend of Eio.

Continuing the previous theme of dabbling with matters agentic. Previously, I’d quite assiduously kept my fingers away from files. This time, I wanted to try something exploratory, switching to the agent for things I was actively stuck on.

Over the summer, Lucas Ma has been investigating ideas surrounding using effects in the OCaml compiler itself. He’s blogged some of his discoveries and adventures. The technical core of this work leads towards being able to use the OCaml compiler as a library on-demand to create a longer-lived “compiler service”. Of itself, that’s not at all revolutionary, but it is quite hard to do that with a 30 year old codebase that really was designed for single-shot separate compilation.