OCaml Weekly News

Four months after the release of OCaml 5.3.0, the set of new features for the future version 5.4.0 of OCaml has been frozen. We are thus happy to announce the first alpha release for OCaml 5.4.0.

This alpha version is here to help fellow hackers join us early in our bug hunting and opam ecosystem fixing fun (see below for the installation instructions) [^1].

The progresses on stabilising the ecosystem are tracked on the opam readiness for 5.4.0 meta-issue.

The full release is expected around the end of July [^2].

If you find any bugs, please report them on OCaml's issue tracker.

If you are interested in the ongoing list of new features and bug fixes, you can have a look at the changelog for OCaml 5.4.0.

Happy hacking, Florian Angeletti for the OCaml team

The latest update 2.3.202505282324 (see top post for links) has several fixes:

1. Using ./dk -O ReleaseSmall Exe now has a working Windows target. The generated Windows executables do not require Visual Studio at runtime.
2. A use-after-free bug has been fixed which mainly affected cross-compilation for the Linux target.
3. Using a new ./dk gc clear command will remove all the cache space.
4. A bug has been fixed with the auto-updates where it downloaded up to 5 updates and then reverted to the original.

https://kcsrk.info/ocaml/modes/2025/05/29/uniqueness_and_behavioural_types/

I wanted a semantic construct to specifically denote unreachable control-flow branches, so here it is. Prints out an error with file and line number upon being erroneously reached.

https://opam.ocaml.org/packages/ppx_unreachable/ppx_unreachable.1.0/

https://www.gridbugs.org/sound-on-ocaml-on-windows/

Dear everyone,

the phase 3 of the opam repository archival (taking the x-maintenance-intent into account) is now ready. We ran on 30th of May the maintenance-intent filter, which resulted in 6463 candidates of which we'd like to archive 5714. The full list is below, the PRs are at https://github.com/ocaml/opam-repository-archive/pull/18 and https://github.com/ocaml/opam-repository/pull/27977.

The proposed merge date is on June 9th, so a week from now.

In case you encounter (a) a breakage or (b) a package and version that you'd like to retain, please report this (best as a comment to https://github.com/ocaml/opam-repository-archive/pull/18)

The list of to-be-archived packages: editor’s note: please see the post link for the long list of packages

It’s 2025, and it’s becoming harder to ignore that LLMs are here to stay, and are changing the way we are programming at large. Or at least, it feels like it.

For a while, I’ve been kind of a gaulois réfractaire myself, when it comes to adopting this technology. Over the month of May, I decided to change that, and at least try to integrate them in my daily toolkit. Since I write OCaml professionally, I picked an arbitrary project in a domain I wasn’t familiar for, to see the impact of LLMs on a more niche language (no offense ahah).

After the fact, I wrote a devlog of the exercise.

In particular, I got myself familiar with EIO in the process, and I wanted to discuss the following part of my article with the OCaml community

My personal conclusion is that LLMs are not ready for any real programming task involving Eio, and I am really curious to understand why. Do they keep hallucinating functions because Eio is a really generic name, and maybe they are mixing context from the Python library with the OCaml one? Or is it because the API of Eio has changed a lot over the years?

I am also wondering how, as a the author of a library, I can fix a similar situation. Assuming ChatGPT starts assuming false statements about cohttp-connpool-eio, how do I address this? I suspect being “LLMs-friendly” will be increasingly important for a software library’s success.

For a while, people learnt to become search engine friendly. They turned themselves into export of Google algorithm, etc. Will we do the same thing with LLMs? Are there guidelines? How can we “fix” at our level a situation where a LLM got a software library we wrote completely wrong?

I’d be curious to hear your thoughts.