OCaml Weekly News

We, at Tarides, are very happy to announce some improvements made to Merlin’s signature-help feature!

As a reminder, signature-help is a feature in Merlin that displays the function signature and highlights the active parameter. In the editor, this is typically displayed in a tooltip, floating window, or minibuffer. For instance, the following image displays the signature-help for the function exec_prog in VSCode.

The implementation of the signature-help command had a few shortcomings, which have been fixed. These fixes are making the feature way more pleasant to use. Some of these improvements are already part of the last Merlin and ocaml-lsp releases, others will be included in the next release.

Results:

• Merlin only displays signature-help information on the function parameters and no longer displays it on the function name.
• signature-help displays the function's information only for the active parameters, and no longer loops back to highlight the first parameter after the last one.
• signature-help is now triggered even if used inside a let .. in binding, in which the in is not yet written after the function call
• The optional parameters are now detected and highlighted when the active parameter starts writing one.

Hi everyone, I am preparing the OCaml Users Survey 2026 on behalf of the OCSF and would like your input on the survey questions before we finalize them.

You can find the proposed question list here: Proposed OCaml Users Survey Questions 2026 For reference, there is a summary of the changes compared to the 2023 survey.

Hi everyone,

on behalf of the OCSF, I am happy to announce the (belated) report on the responses to the OCaml Users Survey 2023. We apologize for the delay in evaluating and are committed to run the OCaml Users Survey reliably in a yearly fashion from now on.

Without further ceremony, here is the link to the report:

https://ocaml-sf.org/docs/2023/survey-results.html

We welcome any feedback on the report, discussion around the responses and numbers (please share your interpretations and opinions), or other commentary.

Thank you to everyone who participated in the survey to help us better understand the state of OCaml and its ecosystem! :orange_heart: :two_hump_camel:

Sabine

PS: the 2026 OCaml Users Survey is coming up. We greatly value your input on the feedback thread about 2026 survey question changes.

Hi! We, at Tarides, are very excited to announce the release of ortac-0.8.0 for specification-driven testing!

ortac is a tool in the Gospel ecosystem. The core idea is to translate a subset of the Gospel specification language into OCaml code and use these translations to generate runtime checking.

ortac has a plugin architecture. You can install it via opam:

$ opam install ortac-wrapper    # install the wrapper plugin for runtime assertion checking, with all the other necessary parts (runtime and cli)
$ opam install ortac-qcheck-stm # install the qcheck-stm plugin that generates QCheck-STM tests, with all the other necessary parts (runtime and cli)
$ opam install ortac-dune       # install the dune plugin to generate dune boilerplate to use the two previous plugins

This release focuses on making Ortac/QCheck-STM take advantage of more features from the QCheck-STM test framework: namely testing in a parallel context and flexibility of the command generation.

You can take a look at the documentation that explains how it works.

Regarding testing in a parallel context, with the introduction of the bug report feature in version 0.2 and the coverage of SUT-returning functions in version 0.4, it was not possible anymore to easily generate QCheck-STM tests in a parallel context (which is quite easy in hand-written QCheck-STM tests). This is now fixed!

Information for the bug report are partly collected in the function doing the actual testing (comparing the results from the actual run and the results from the model). This means that implementing the bug report feature for the parallel testing requires to rewrite this function, which is the heart of QCheck-STM+Domains and what we are trusting when running the tests (the Trusted Testing Base if you will). In order to check that we keep the same behaviour, that the generated tests have the same semantic as corresponding hand-written QCheck-STM tests, we minimized the diff of the commit introducing the collection of the information so that the preservation of the logic is apparent (at the end of the day, human review is what we trust).

Since version 0.4, SUT-returning functions are included in the tests. The newly created SUT is then added to the store of SUTs that are picked as argument for the next calls. The question here is what to do with them in a parallel context: We can't add a SUT created in a parallel branch in a global store, as it is not supposed to be shared between domains. We've chosen a simple design, where we stop storing newly created SUTs once we are in a parallel context. No worries, these SUT-returning functions will still be fully tested in the sequential part of the testing (in sequential mode and/or in the sequential prefix of the parallel mode).

One of the power of the QCheck-STM test framework is the flexibility of its command generator. This flexibility comes from the QCheck.Gen API itself and from the fact that the QCheck-STM command generator is parameterized over the state of the current model (think generation of a lookup command for a key-value store, you want to be able to have a chance to generate a call that lookup a key that is actually associated to a value). An automatically generated command generator ought to be a bit naive. In order to mitigate this naiveté, we allow the user to provide:

• weights to be applied to specific command generation, usefull for example to disable the generation of the push command on a work stealing queue on the domain that is not supposed to own the queue.
• complete command generator implementation when the user wants to take advantage on the command generator being parameterized over the current state of the model.

Happy testing!

With the progress of the ongoing stabilisation effort for OCaml 5.5.0, we are happy to announce a third alpha release for OCaml 5.5.0.

The missing second alpha was unreleased due to an unforeseen interaction between the relocatable compiler and bootstrapping. This issue is fixed in this third alpha.

Beyond this important change, compared to the first alpha this new alpha release contains

• two code generation fixes
• three type system fixes
• one standard library fix

(see the Changelog below for a full list).

Overall, it looks like 5.5.0 is stabilizing quite well and alpha versions of most development tools are available. Thus we are planning to switch to a beta release in the beginning of April.

More precisely, the ongoing progress on stabilising the ecosystem is tracked on the 5.5.0 readiness meta-issueon opam.

There is also a companion alpha opam repository available for this alpha release

$ opam repo add alpha git+https://github.com/kit-ty-kate/opam-alpha-repository.git

which contains in-progress alpha releases of opam packages that are being updated for OCaml 5.5.0 .

The final release is still planned for between May and June.

If you find any bugs, please report them on the issue tracker.

If you are interested by the full list of new features and bug fixes, the updated changelog for OCaml 5.5.0 is available.

Happy hacking, Florian Angeletti for the OCaml team

Hello,

I just made a first release of ocaml-openapi-gen, a tool generating code from an openapis specification.

The openapi_gen package is available from my personal opam repository.

This tool is used to generate code for ocaml-forgejo, a library to interact with Codeberg and other forgejo-based platforms through the provided REST API.

The generated interfaces way evolve in the future.

I’m currently teaching a course called “CS6868: Concurrent Programming” at IIT Madras. The goal of the course is to teach concurrent and parallel programming using OCaml 5, and then introduce OxCaml for safe and fast parallelism. I’ve covered the OCaml 5 parts, and will be starting OxCaml next. I thought it would be good to share the course materials with the community.

https://github.com/kayceesrk/cs6868_s26

CS6868 assumes knowledge of OCaml, which I cover in CS3100: Paradigms of Programming. This course includes a YouTube playlist with all the lectures, notebooks, and assignments.

CS6868 builds the foundations of parallelism, reasoning about correctness through linearizability, parallel programming through spin locks, mutexes, condition variables, memory consistency models, and the basics of performance and non-blocking data structures (lock-free linked lists, queues, and stacks). Here, the course closely follows the book The Art of Multiprocessor Programming. All the code has been redone in OCaml 5. In addition to the book content, the course also covers the OCaml relaxed memory model. We also cover a fair bit of OCaml-specific tools here, including concurrent property-based testing using qcheck-lin and qcheck-stm, and data race detection using TSAN.

Following this, the course covers the basics of effect handlers, following specific parts of Control structures in programming languages: from goto to algebraic effects. We then build a full-fledged Go-like, multicore-capable concurrent programming library with lightweight threads, buffered channels, selective communication (in the vein of Concurrent ML), nested parallel programming (as in domainslib), and basic asynchronous IO (as in Eio).

There is a growing collection of course projects, which should be doable if you’ve gone through the course materials. Let me know if you have ideas for course projects.

The course tries to bring together the content from many tutorials we have done in the past. Let me know if you have feedback. I’m open to accepting PRs fixing small issues, but given that this is an ongoing course, any large PRs will likely not be accepted. I hope you will enjoy working through this as much as I had fun making it.

I'm pleased to announce the first release of libinput-ocaml (OCaml bindings for the libinput C library).

libinput is used by applications such as Wayland compositors to access mice, keyboards, touch pads, etc.

Linux input devices (with libinput-ocaml) explains how input devices work on Linux, and shows how to use the library to create a little game:

I propose to hold OCaml compiler office hours on Friday April 3d, 11:00-12:00 UTC (in local time, [date-range from=2026-04-03T11:00:00 to=2026-04-03T12:00:00 timezone=UTC].)

• collaborative pad to prepare questions/topics