OCaml Weekly News

Previous Week Up Next Week


Here is the latest OCaml Weekly News, for the week of October 10 to 17, 2023.

Table of Contents

Hiring Functional Software Engineers (OCaml or Haskell) in Paris, France!

Christian announced

Hey team! Tweag is hiring a Functional Software engineer with Experience in OCaml or Haskell, if you’re fluent in ant of these languages please feel free to apply. This is an onsite position at our client offices located in Paris, France. (Hybrid model can be discussed in the interview process)

If you want to lear more and how to apply please follow this link where you’ll see all the information: https://grnh.se/51d5e65b3us

Any questions let me know!

OCaml Hacking Day at Tarides Chennai

Sudha Parimala announced

We’re running an OCaml Hacking event at the Tarides office in Chennai on the 21st of October.

We’re excited to hack on a diverse range of OCaml projects, including the compiler, concurrency libraries, and tooling, as well as benchmarking projects. Folks from Tarides will be around to assist with questions and support participants.

This is an in-person event in Chennai. For more details and registration, please visit https://forms.gle/9vNd4UyJejqJR5sMA. Looking forward to seeing some of you there!


qcheck-lin and qcheck-stm 0.2

Jan Midtgaard announced

FYI, we just rolled out a 0.3 release of qcheck-lin, qcheck-stm, and qcheck-multicoretests-util: https://github.com/ocaml-multicore/multicoretests/releases/tag/0.3 The release should be available in an opam repo near you shortly… :wink:

The 0.3 release brings 3 “usability improvements” to STM and Util and a Lin search improvement that should reduce memory allocation.

  • #400: Catch and delay exceptions in STM’s next_state for a nicer UX
  • #387: Reduce needless allocations in Lin’s sequential consistency search, as part of an Out_channel test cleanup
  • #379: Extend the set of Util.Pp pretty-printers and teach them to add break hints similar to ppx_deriving.show; teach to_show to generate truncated strings when $MCTUTILS_TRUNCATE environment variable is set
  • #368: Switch STM_domain.agree_prop_par_asym from using Semaphore.Binary to using an int Atomic.t which improves the error rate across platforms and backends

Happy testing! :smiley:

dune 3.11.0

Etienne Millon announced

We just released dune 3.11.1 with the following fixes:


  • Fix dune rpc commands on Windows (#8806, fixes #8799, @nojb)
  • Fix inline_tests when the partition list is empty (#8849, fixes #8848, @hhugo)

runtime_events_tools 0.5.0

Sudha Parimala announced

I’m happy to announce the release of runtime_events_tools.0.5.0.

OCaml 5.0 introduced a new ring-buffer based tracing system with low overheads. This eliminated the need for a separate tracing runtime and added the ability to keeping tracing on by default. The OCaml runtime uses this tracing system to track GC events. OCaml 5.1 went further to include support for custom events.

Runtime events tools through olly, provides functionality to grok the data provided by the runtime tracing system.

Olly has two modes; trace , and gc-stats

olly trace

$ olly trace example.trace example.exe

Records runtime traces in fuchsia and json formats. The trace files can be visualised with ui.perfetto. or json trace with [chrome://tracing](chrome://tracing).

Here’s a sample trace rendered in perfetto.


olly gc-stats

Provides information about GC time and latencies.

$ olly gc-stats "binarytrees5_multicore.exe 2 20"

Execution times:
Wall time (s):	2.61
CPU time (s):	4.63
GC time (s):	2.93
GC overhead (% of CPU time):	63.18%

GC time per domain (s):
Domain0: 	1.59
Domain1: 	1.34

GC latency profile:
#[Mean (ms):	0.76,	 Stddev (ms):	1.56]
#[Min (ms):	0.00,	 max (ms):	15.68]

Percentile 	 Latency (ms)
25.0000 	 0.00
50.0000 	 0.01
60.0000 	 0.04
70.0000 	 0.28
75.0000 	 0.66
80.0000 	 1.40
85.0000 	 2.44
90.0000 	 3.16
95.0000 	 3.62
96.0000 	 3.79
97.0000 	 4.06
98.0000 	 4.73
99.0000 	 6.29
99.9000 	 13.59
99.9900 	 15.68
99.9990 	 15.68
99.9999 	 15.68
100.0000 	 15.68

New features in this release:

  • Support for fuchsia format: Stores the trace in binary format, making the trace files 4x smaller in size, on an average.
  • gc-stats mode: In addition to latency percentiles, GC stats provide more insights, such as GC time and GC time spent per domain.
  • Custom events support: Not only can you trace GC events, but now you can also trace your own events a32a3bd2f83a24ce0f1580f749970437b384d8d8_2_1380x182.png

    Trace for a recursive fibonacci function

Note that if you see non-terminating events in your traces, you might want to include this compiler patch – https://github.com/ocaml/ocaml/pull/12583.

Gospel 0.2.0

Nicolas Osborne announced

We are very happy to announce the release 0.2.0 of gospel!

Gospel is a tool-agnostic behavioural specification language for OCaml. It allows you to write strongly typed contract-based specifications for your OCaml libraries (for a reasonable subset of OCaml). Gospel’s syntax has been designed to be easy to learn for an OCaml programmer. You can access the documentation here.

This release adds two main features, a gospel dumpast command and a gospel.ppx ppx rewriter to display Gospel specification as documentation with odoc.

Some minor extensions have been added to the language itself:

  • a with construct to name a variable in type invariants referring to a value of the specified type,
  • int literals,
  • anonymous functions now support both patterns in arguments and return type annotations,
  • unit result in function headers,
  • constants can now be referenced in specifications,
  • infix operators are now accepted in specification headers.

Parser, preprocessor, and error messages have been improved. In particular the preprocessor can now handle large files and locations are properly tracked. Pattern matches are now also checked for exhaustiveness and redundancy.

We have made a number of improvements and bugfixes in the type checker as well as some minor modifications in the Gospel standard library. Finally, the documentation has been revised.

Talk about declarative rhythm-machines with Fry and FRP @ Copenhagen

rand announced

I’m happy to announce that I’m doing a talk on Fry at meetup for functional copenhageners @ 24. october. Fry is a small library that enables declarative definitions of rhythm-machines etc. together with FRP (React). These can be interactive, generative, experimental - what ever you fancy. Recently I’ve used it for a polyrhythmic machine (pmmd) based on bpm-modulation, that I’m planning on releasing as modular synthesizer hardware.

A couple of concepts from Fry that are interesting, which you can see from its examples:

Also, OCaml with first class modules + module functors + FRP, map elegantly to the semantics of modular synthesizers. Simply:

  • a unit event maps to a control-voltage (CV) trigger
  • a float signal maps to CV
  • a module functor maps to a modular synth module taking CV-in, exposing CV-out

If you are near Copenhagen - hope to see you (:

Deprecating ocaml-migrate-parsetree in favor of Ppxlib, also as a Platform tool

Sonja Heinze announced

Hello everyone :wave:

We’re planning to deprecate ocaml-migrate-parsetree (OMP) finally. OMP forms part of the OCaml Platform, so we can’t and wouldn’t just do that without the approval of the community. So first a bit of context:

What is OMP anyways?

OMP used to be an extremely important project in the meta-programming-related chunk of OCaml’s ecosystem. Since the introduction of extension nodes and attributes in OCaml 4.2 in 2014, meta-programming in OCaml is most commonly done on OCaml’s parsetree. The caveat: The parsetree is extended and modified between OCaml minor versions, meaning that handling the OCaml parsetree directly is unstable. OMP came to the rescue by introducing a concept we call versioned parsetrees (or versioned ASTs) together with migrations between those fixed versions of the parsetree, allowing the workflow


That workflow allows one PPX to guarantee compatibility with multiple compiler versions (here, PPX = PreProcessor eXtension stands for the meta-programming instance). That was extremely important at the time to introduce a more version-flexible ecosystem and to reduce the maintenance burden of PPXs!

OMP also provided the concept of a driver, which is one single binary driving the applicatoin of all PPXs. Without that, using n PPXs would mean copying the workflow pictured above n times. That’s an incredible performance overhead. The OMP driver took care of applying all PPXs, so fewer parsetree migrations and less communication between different processes were necessary (before: one process per PPX).

Why was OMP not enough?

However, the OMP driver was still duplicating parsetree migrations, and it did one whole parsetree pass per PPX. And because of the latter, the outcome of the preprocessor phase used to depend on the order of PPXs, which didn’t follow any semantically relevant or otherwise reasoned pattern. The reason why it would have been extremely complicated to improve the OMP driver further was that each PPX chose its own versioned parsetree version. There was no agreement between different PPXs.

  • Ppxlib

    So the solution was to have the PPXs agree on one versioned parsetree version. That’s what Ppxlib does. It also does a lot more by providing an extensive API to write PPXs easily and others, but the main point here is that it consolidates a consistent PPX ecosystem wrt parsetree versions. The way it does so is by exposing one fixed versioned parsetree version that all PPXs are defined against.

    Thanks to that, the Ppxlib driver can get rid of unnecessary parsetree migrations, and it can merge a whole bunch of PPXs into one AST pass, improving performance and guaranteeing a clear order of PPX transformations. Also important: Having all PPXs on the same versioned parsetree version, makes it easy to have them all on the one of the latest OCaml version. For details I’m not going into, that’s the only (reasonable) way to have the PPXs support the latest compiler syntax features, so that’s a huge advantage of Ppxlib as well.

    Ppxlib still isn’t perfect and comes with its own little set of problems, but it does solve the mentioned big problems of performance overhead, unclear composition semantics, parsetree-version-fragmentation among different PPXs, and lack of latest compiler syntax support. So by now, the whole OCaml opam ecosystem has shifted from OMP to Ppxlib (more below).

    The latest update on the state of Ppxlib, also including info about OMP and the ecosystem’s transition from one to the other is this one from 2021. All Ppxlib maintainers have very very little time for communication and similar. If a new update would be strongly appreciated, let us know. For here, let’s focus on OMP:

What does it mean to deprecate OMP?

Given that by now, OMP’s maintenance is held at the bare bare minimum anyways, deprecating it would only have one clear impact:

  • Real-life

    We’d stop adding new compiler support, so the last supported compiler would be OCaml 5.0. Concretely: We won’t add the new versioned parsetrees and migrations for the new compilers anymore.

  • Formalities

    We’d also mark the OMP opam packages as deprecated, and we’d move OMP to the Deprecate section in the set of OCaml Platform tools (now it’s in the Sustained section).

Is it ok to deprecate OMP?

You tell us :) Here’s some info:

  • Opam packages

    All packages on opam have moved to Ppxlib now. There’s only a hand-full of packages that formally still depend on OMP, but all of that seems to be formal left-overs in the opam files, a left-over test dependency or similar. I’ve opened issues on those packages, mentioning the potential upcoming deprecation of OMP, and nobody has complained.

  • Distribution packages

    There are still a few distributions that keep on packaging OMP on their distribution, e.g. there’s OMP on Debian, OMP on Fedora and OMP on Arch. However, the reason for that seems merely historical (with unquestioned inertia): There are no reverse dependencies on Debian or Fedora. On Arch, there are a few reverse dependencies, none of them still being relevant in the present. I’ll reach out to the three respective package managers. If anyone has any info or relevant context about this, please share it!

  • Users/community

    And this is where we’re asking for feedback. Does it sound good to everyone to deprecate OMP? We do have the strong impression that pretty much everyone has moved to Ppxlib, but if you think we’re missing something important, please let us know (or, just use this opportunity to say something nice about OMP :slight_smile: ).

  • Original author and current maintainer

    Obviously, the current maintainer/“sustainer” (me) thinks it’s good to deprecate OMP finally. And the original author, @let-def, is behind it as well.

    Btw, @let-def, thanks a lot for this crucial piece of OCaml software! It contains a lot of really good ideas, concepts, and implementation details! Even once deprecated, it will persist - partly quite literally inside Ppxlib in the form of the versioned parsetrees, the migrations, and parts of the driver.


If you happen to miss a CWN, you can send me a message and I’ll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe to the caml-list.