OCaml Weekly News

Previous Week Up Next Week


Here is the latest OCaml Weekly News, for the week of April 06 to 13, 2021.

Table of Contents

ocaml-wayland (pure OCaml wayland protocol library)

Thomas Leonard announced

I've just released ocaml-wayland, a pure OCaml Wayland implementation. You can get it with:

opam install wayland

Wayland is a communications system intended for use between processes on a single computer. It is mainly used by graphical applications (clients) to talk to display servers, but nothing about it is specific to graphics and it could be used for other things.

A Wayland protocol is defined by writing a schema file. Typed bindings can then be created automatically from that for various languages. Wayland's main interesting feature is that you can pass file descriptors as message arguments. For example, to send a frame of video you can get a file descriptor to some shared memory, draw the image to it, and then pass the FD to the server for rendering, with no need to copy the data.

The ocaml-wayland library can be used to write applications, display servers, or proxies. The example in the repository opens a window showing some scrolling squares. Clicking reverses the direction and pressing keys changes the colours.

I used the library to write wayland-virtwl-proxy, which allows applications running in VMs to open windows directly on the host desktop, as described in my recent blog post "Qubes-lite with KVM and Wayland".

Note that, unlike the older X11 protocol, Wayland doesn't provide any graphics primitives (such as drawing rectangles or text). Instead, applications render the window contents however they please and then simply share the buffer with the compositor. So if you want to write a normal application using it, you'll need to find or write a separate GUI toolkit too.

Reparse v2.1.0 release

Bikal Lem announced

I have just released v2.1.0 of reparse to opam. Below are the CHANGES for this release. CHANGES:

This release has backwards incompatible changes.

  • Infix functions are now available (opened by default) in Parser module itself.
  • Add support for let operators - let+ , let* , and+ and and* .
  • bind and map function are now labelled following base library dependency convention.
  • Items in all_unit are now unit t rather than _ t following monad combinator convention in base library dependency.
  • pure is now deprecated. Use return instead. This is to stay consistent with monad conventions in base library dependency.
  • >|= is deprecated. Use >>| instead. This is to stay consistent with monad conventions in base library dependency.
  • Removed map4 function.
  • Add support for ppx_let .
  • Deprecate Parser module. Use Reparse instead.

Open source editor for iOS, iPadOS and macOS

Nathan Fallet announced

I'm proud to share with you the editor I've been working on theses last weeks, which is also open source!

The editor is available here: App Store link And the source code here: GitHub repository

A Pull Request just got merged, it is now part of the "Mobile" section on the Install page on the OCaml website.

Feel free to give your feedback, and/or contribute to the project on GitHub to help us to make a better tool!

EduardoRFS then said and borisd replied

I have dream, a day where this kind of app will be written in OCaml

I've done some experimental Cocoa bindings, and the basics are working, but the scope of the project is too large for a single person effort. Here's an example basic app: https://github.com/dboris/ocaml-cocoa/blob/master/examples/count_clicks.ml

Would be interested to contribute to a project with a similar goal, if someone has a better idea how to approach this.

Yawar Amin added

Jeffrey Scofield has built some iOS apps with OCaml, so it's certainly possible: https://psellos.com/ocaml/compile-to-iphone.html

Returning to the original post, Nathan Fallet answered a question

Yes, this app can be used offline!

It works with a toplevel built with js_of_ocaml, stored in the app, and everything runs on the device (You can browse on GitHub the OCaml/JavaScript/ folder which contains the toplevel itself). So as everything is already built-in, no internet connection is required.

I will clarify it on the App Store page, because even if it was evident for me, I notice it is not for everyone.

Last thing, I'm myself in CPGE (MPSI to be exact), and that's the reason why I started working on this app on my free time.

Lilian Besson asked and Nathan Fallet replied

  • how is automated the build and the upload of the app on the App Store? If a new OCaml version comes every couple of months, how much time would it require to rebuild and upgrade the app and publish/update it on the App Store?
  • I build the app manually, and upload the file to the App Store. So if a new version of OCaml is released, I need to rebuild the top level with Js_of_ocaml, and build a new version of the app that I upload.
  • Can users save (export) and import .ml files? If so, advertise this feature too! Can users write in more than one file at a time (like it's possible for BetterOCaml.ml in a single browser tab!)
  • Users can open and save their .ml files, and even open them from the file explorer (double click on a .ml file will open it in the app), it's like a real code editor. For now only one file can be opened at time, but I plan to make a way to open multiple files (still thinking about it…)
  • I guess I know the answer but… the technology you chose to build the app is limited to Apple-products only, and it's not a cross-platform technology like Flutter.dev or others recent technologies based on HTML/CSS/Javascript? If it is, how hard do you think it would be for you to also publish your app on Google Play store, and F-Droid.org ? The only app on Google Play is 10 year-old, for OCaml 3.12! https://play.google.com/store/apps/details?id=fr.vernoux.ocaml, it would be so great to publish a more recent and modern alternative!
  • Of course I wrote the app with pure Swift (except the top level which is built with JS), but an Android version of the app can be written without problem (it's just about the user interface), and then published to the Google Play Store and whatever other store for Android phones.

As holidays are starting now in France, I will consider improving the app with feedbacks I got those last days, publish an update to the App Store, and start working on an Android version.

OCaml Café - Tue, Apr 13 @ 7pm Central

Claude Jager-Rubinson announced

Please join us this coming Tuesday, April 13 at 7pm Central for OCaml Café. Zoom info is at https://hfpug.org/event/ocaml-cafe-3/

OCaml Café offers a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions.

Whether you’re still trying to make sense of currying or can spot non-tail-recursive code from across the room, we hope that you’ll join us with your questions about OCaml, or just to hang out with the OCaml community.

Directories, an ocaml library

zapashcanon announced

We released directories 0.3 recently. In this release, we dropped the Windows dependency on ctypes-foreign and use ctypes.stubs instead. See #10

This allowed us to clean the code and to remove some dirty hacks.

Multicore OCaml: March 2021

Anil Madhavapeddy announced

Welcome to the March 2021 Multicore OCaml monthly report! The following update and the previous ones have been compiled by me, @kayceesrk and @shakthimaan. We remain broadly on track to integrate the last of the multicore prerequisites into the next (4.13) release, and to propose domains-only parallelism for OCaml 5.0.

Upstream OCaml 4.13 development

The complex safe points PR (#10039) is continuing to make progress, with more refinement towards reducing the binary size increase that results from the introduction of more polling points. Special thanks to @damiendoligez for leaping in with a PR-to-the-PR to home in on a workable algorithm!

Multicore OCaml trees

If there's one thing we're not going to miss, it's git rebasing. The multicore journey began many moons ago with OCaml 4.02, and then 4.04, 4.06, and the current 4.10. We're pleased to announce the hopefully-last rebase of the multicore OCaml trees to OCaml 4.12.0 are now available. There is now a simpler naming scheme as well to reflect our upstreaming strategy more closely:

  • OCaml 4.12.0+domains is the domains-only parallelism that will be submitted for OCaml 5.0
  • OCaml 4.12.0+domains+effects is the version with domains parallelism and effects-based concurrency.

You can find opam installation instructions for these over at the multicore-opam repository. There is even an ocaml-lsp-server available, so that your favourite IDE should just work!

Domains-only parallelism trees

The bulk of effort this month has been around the integration and debugging of Domain Local Allocation Buffers (DLABs), and also chasing down corner-case failures from stress testing and opam bulk builds. For details, see the long list of PRs in the next section.

We're also cleaning up historical vestiges in order to reduce the diff to OCaml trunk, in order to clear the path to a clean diff for generating OCaml 5.0 PRs for upstream integration.

Concurrency and Effects trees

The camera-ready paper for PLDI 2021 on Retrofitting Effect handlers onto OCaml is now available on arXiv. The code described in the paper can be used via the 4.12.0+domains+effects opam switches. Please feel free to keep any comments coming to @kayceesrk and myself.

We've also been hacking on the multicore IO stack and just beginning to combine concurrency (via effects) and parallelism (via domains) into Linux io_uring, macOS' Grand Central Dispatch and Windows iocp. We'll have more to report on this over the next few months, but early benchmarking numbers on Linux are promising.

CI and Benchmarking

We are continuing to expand the testing for different CI configurations for the project. With respect to Sandmark benchmarking, we are in the process of adding the Irmin layers.ml benchmark. There is also an end-to-end pipeline of using the OCurrent current-bench framework to give us benchmarking results from PRs that can be compared to previous runs.

As always, we begin with the Multicore OCaml updates, which are then followed by the ongoing and completed tasks for the Sandmark benchmarking project. Finally, the upstream OCaml work is listed for your reference.

Detailed Updates

Multicore OCaml

  • ocaml-multicore/ocaml-multicore#484 Thread allocation buffers

    The PR provides an implementation for thread local allocation buffers or Domain Local Allocation Buffers. Code review and testing of the changes is in progress.

  • ocaml-multicore/ocaml-multicore#508 Domain Local Allocation Buffers

    This is an extension to the Thread allocation buffers PR with initialization, lazy resizing of the global minor heap size, and rebase to 4.12 branch.

  • ocaml-multicore/ocaml-multicore#522 Building the runtime with -O0 rather than -O2 causes testsuite to fail

    The runtime tests fail when using -O0 instead of -O2 and this needs to be investigated further.

  • ocaml-multicore/ocaml-multicore#526 weak-ephe-final issue468 can fail with really small minor heaps

    The weak-ephe-final tests with a small minor heap (4096 words) cause the issue468 test to fail.

  • ocaml-multicore/ocaml-multicore#528 Expand CI runs

    A list of requirements to expand the scope and execution of our existing CI runs for comprehensive testing.

  • ocaml-multicore/ocaml-multicore#514 Update instructions in ocaml-variants.opam

    The ocaml-variants.opam and configure.ac files have been updated to use the Multicore OCaml repository, and to use a local switch instead of a global one. The current Multicore OCaml is at the 4.12 branch.

  • ocaml-multicore/ocaml-multicore#523 Systhreads Mutex raises Sys_error

    The error checking for Systhreads Mutex should be inline with trunk, instead of the fatal errors reported by Multicore OCaml.

  • ocaml-multicore/ocaml-multicore#527 Port eventlog to CTF

    The eventlog implementation has to be ported to the Common Trace Format. The log output should be consistent with the parallel_minor_gc output, and stress testing need to be performed.

  • ocaml-multicore/ocaml-multicore#490 Remove getmutablefield from bytecode

    The bytecode compiler and interpreter have been updated by removing the getmutablefield opcodes.

  • ocaml-multicore/ocaml-multicore#496 Replace caml_initialize_field with caml_initialize

    A patch to replace caml_initialize_field, which was earlier used with the concurrent minor collector, is now replaced with caml_initialize.

  • ocaml-multicore/ocaml-multicore#503 Re-enable lib-obj and asmcomp/is_static tests

    The lib-obj and asmcomp/is_static tests have been re-enabled and the configure settings have been updated for Multicore NO_NAKED_POINTERS.

  • ocaml-multicore/ocaml-multicore#506 Replace Op_val with Field

    The use of Op_val (x)[i] has been replaced with Field (x, i) to be consistent with trunk implementation.

  • ocaml-multicore/ocaml-multicore#507 Change interpreter to use naked code pointers

    The changes have been made to identify naked pointers in the interpreter stack to be compatible with trunk.

  • ocaml-multicore/ocaml-multicore#516 Remove caml_root API

    The caml_root variables have been changed to value type and are managed as generational global roots. Hence, the caml_root API is now removed.

  • ocaml-multicore/ocaml-multicore#511 Allocate unique root token on the major heap instead of the minor

    The unique root token allocation is now done on the major heap allocation that does not raise any exception, and exits cleanly when a domain creation fails.

  • ocaml-multicore/ocaml-multicore#513 Clear the minor heap at the end of a collection in debug runtime

    A debug value is written to every element of the minor heap for debugging failures. We now clear the minor heap at the end of a minor collection.

  • ocaml-multicore/ocaml-multicore#519 Make timing test more robust

    The timing.ml test has been updated to be more resilient for testing with DLABs.

  • ocaml-multicore/ocaml-multicore#477 Move TLS areas to a dedicated memory space

    In order to support Domain Local Allocation Buffer, we now move the TLS areas to its own memory alloted space thereby changing the way we allocate an individual domain's TLS.

  • ocaml-multicore/ocaml-multicore#480 Remove leave_when_done and friends from STW API

    The barriers from caml_try_run_on_all_domains* and stw_request are removed by cleaning up the stw_request.leave_when_done implementation.

  • ocaml-multicore/ocaml-multicore#481 Don't share array amongst domains in gc-roots tests

    Every domain should have its own array, and the parallel global roots tests have been updated with this change.

  • ocaml-multicore/ocaml-multicore#494 Stronger invariants on unix_fork

    We now enforce stronger invariants such that no other domain can run alongside domain 0 (caml_domain_alone) for unix_fork.

  • ocaml-multicore/ocaml-multicore#515 Add memprof stubs to build and stdlib

    The required memprof functions have been added to build stdlib, and also to build memprof for the runtime.

Lazy Updates
  • ocaml-multicore/ocaml-multicore#487 systhreads: set gc_regs_buckets and friends to NULL at thread startup

    Pointers have been initialized to NULL in systhreads/st_stubs.c which solves the segmentation fault observed when running the Layers benchmark.

  • ocaml-multicore/ocaml-multicore#491 Reinitialize child locks after fork

    The runtime needs to operate correctly after a fork, and this patch fixes it with proper resetting of domain lock.

  • ocaml-multicore/ocaml-multicore#495 Fix problems with finaliser orphaning

    A fix for how we merge finalization tables for orphaned finaliser work. A test case has also been added to the PR.

  • ocaml-multicore/ocaml-multicore#499 Fix backtrace unwind

    The unwinding of stacks over callbacks was not happening correctly and the discrepancy in caml_next_frame_descriptior is now resolved.

  • ocaml-multicore/ocaml-multicore#509 Fix for bad setup of Continuation_already_taken exception in bytecode

    A patch to fix the Continuation_already_taken exception which was not set up as needed in the bytecode execution.

  • ocaml-multicore/ocaml-multicore#510 Update a testcase in principality-and-gadts.ml

    A change in principality-and-gadts.ml to log the correct output as compared to 4.12 branch in ocaml/ocaml.

  • ocaml-multicore/multicore-opam#46 Multicore compatible ocaml-migrate-parsetree.2.1.0

    The ocaml-migrate-parsetree package uses the effect syntax and now builds with Multicore OCaml parallel_minor_gc branch.

  • ocaml-multicore/multicore-opam#47 Multicore compatible ppxlib

    The effect syntax has been added to ppxlib and is also now compatible with Multicore OCaml.

  • ocaml-multicore/multicore-opam#49 4.12 Multicore configs

    Added configurations to install 4.12.0+domains+effects and 4.12.0+domains OCaml variants.

  • ocaml-multicore/ocaml-multicore#473 Building on musl requires dynamically linked execinfo

    The opam files to allow installation on musl-based environments for Multicore OCaml have been added to the repository.

  • ocaml-multicore/ocaml-multicore#482 Check for -lexecinfo in order to build on musl/alpine

    A configure script has been added which checks for -lexecinfo in order to support building Multicore OCaml on musl/alpine.

  • ocaml-multicore/ocaml-multicore#502 Update README to introduce 4.12+domains+effects and 4.12+domains

    We have updated the README file with the current list of active branches, and the names of the historic variants.

  • ocaml-multicore/ocaml-multicore#520 Clarify comment on RacyLazy

    A documentation update in stdlib/lazy.mli that clarifies when RacyLazy and Undefined are raised.

  • ocaml-multicore/ocaml-multicore#486 Sync no-effects-syntax to parallel_minor_gc branch

    The ocaml-multicore:no-effects-syntax branch is now up to date with the parallel_minor_gc branch changes.

  • ocaml-multicore/ocaml-multicore#489 Remove promote_to

    The promote_to function was used in the concurrent minor GC. It is not required any more and hence has been removed.

  • ocaml-multicore/ocaml-multicore#500 Replace caml_modify_field with caml_modify

    The caml_modify_field is no longer necessary and has been replaced with caml_modify.


  • ocaml-bench/sandmark#204 Adding layers.ml as a benchmark to Sandmark

    The inclusion of Irmin layers.ml benchmark with updates to all its dependency requirements.

  • ocaml-bench/sandmark#209 Use rule target kronecker.txt and remove from macro_bench

    A review of the graph500seq kernel1.ml implementation has been done, and code changes have been proposed. The macro_bench tag will be retained for the graph500 benchmarks.

  • ocaml-bench/sandmark#212 Increasing the major heap allocation on some benchmarks

    A work in progress to add more longer running benchmarks that involve major heap allocation. Some of the parameters have been updated with higher values, and more loops have been added as well.

  • We now have integrated the build of Sandmark 2.0 with current-bench for CI. The results of the benchmark runs are now pushed to a PostgreSQL database as shown below:

    docker=# select * from benchmarks;
    -[ RECORD 1 ]--+-------------------------------------------------------
    run_at         | 2021-03-26 11:21:20.64
    repo_id        | local/local
    commit         | 55c6fb6416548737b715d6d8fde6c0f690526e42
    branch         | 2.0.0-alpha+001
    pull_number    |
    benchmark_name |
    test_name      | coq.BasicSyntax.v
    metrics        | {"maxrss_kB": 678096, "time_secs": 101.99969387054443}
    duration       | 00:37:52.776357
    -[ RECORD 2 ]--+-------------------------------------------------------
    run_at         | 2021-03-26 11:21:20.64
    repo_id        | local/local
    commit         | 55c6fb6416548737b715d6d8fde6c0f690526e42
    branch         | 2.0.0-alpha+001
    pull_number    |
    benchmark_name |
    test_name      | thread_ring_lwt_mvar.20_000
    metrics        | {"maxrss_kB": 8096, "time_secs": 2.6146790981292725}
    duration       | 00:37:52.776357

    We will continue to work on adding more workflows and features to current-bench to support Sandmark builds.

  • ocaml-bench/sandmark#202 Added bench clean target in the Makefile

    A benchclean target to remove the generated benchmarks and its results while still retaining the _opam folder has been added to the Makefile.

  • ocaml-bench/sandmark#203 Implement ITER support

    The use of ITER variable is now supported in Sandmark, and you can run multiple iterations of the benchmarks. For example, with ITER=2, a couple of summary .bench files are created with the benchmark results as shown below:

    $ TAG='"run_in_ci"' make run_config_filtered.json
    $ ITER=2 RUN_CONFIG_JSON=run_config_filtered.json make ocaml-versions/4.10.0+multicore.bench
    $ ls _results/
    4.10.0+multicore_1.orun.summary.bench  4.10.0+multicore_2.orun.summary.bench
  • ocaml-bench/sandmark#208 Fix params for simple-tests/capi

    A minor fix in run_config.json to correctly pass the arguments to the simple-tests/capi benchmark execution. You can verify the same using the following commands:

    $ TAG='"lt_1s"' make run_config_filtered.json
    $ RUN_CONFIG_JSON=run_config_filtered.json make ocaml-versions/4.10.0+multicore.bench
  • ocaml-bench/sandmark#210 Don't share array in global roots parallel benchmarks

    A patch to not share array in global roots implementation for parallel benchmarks.

  • ocaml-bench/sandmark#213 Resolve dependencies for 4.12.1+trunk, 4.12.0+domains and 4.12.0+domains+effects

    The dependencies/packages have now been updated to be able to build 4.12.1+trunk, 4.12.0+domains and 4.12.0+domains+effects branches with Sandmark.


  • ocaml/ocaml#10039 Safepoints

    The review of the Safepoints PR is in progress. Special thanks to Damien Doligez for his code suggestions on safepoints and inserting polls. There is still work to be done on optimizations.

Many thanks to all the OCaml users, developers and contributors in the community for their support to the project. Stay safe!


  • API: Application Programming Interface
  • CI: Continuous Integration
  • CTF: Common Trace Format
  • DLAB: Domain Local Allocation Buffer
  • GC: Garbage Collector
  • OPAM: OCaml Package Manager
  • PR: Pull Request
  • STW: Stop The World
  • TLS: Thread Local Storage

Nate asked and Anil Madhavapeddy replied

Sorry if this has been answered elsewhere – am I reading this correctly that effects aren’t intended for OCaml 5? If not, are there plans to merge effect handlers into mainline OCaml at some later stage, or is it going to be kept separate?

Just to be clear, effects are not slated for any official release of OCaml yet. The focus is on making sure that OCaml 5.0 is a really solid release with domains-only parallelism, and then to look into subsequent changes required for concurrency. There are some considerations about how precisely effects should work when they materialise in a mainline OCaml release:

  • semantics: how will the introduction of effect handlers complicate (or improve!) reasoning about OCaml programs? @fpottier and Paulo Emílio de Vilhena have a paper on "separation logic for effect handlers" at POPL 2021 that is a good starting point to read from.
  • performance: on the other side, we want to make sure that effect handlers do not introduce a runtime overhead to sequential OCaml code. Our paper on "retrofitting effect handlers onto OCaml" addresses this, with a particular restriction on making sure handlers are one-shot only (a position conveniently reinforced by @fpottier's paper above, as it also makes program reasoning much easier).
  • type safety: our current implementation of effects is untyped, which doesn't fit that well into the spirit of ML. There is active research ongoing into developing a theory of typed effects lead by @lpw25, and you can see a tech talk about this.
  • portability: OCaml is an extremely portable language, we want to make sure we can maintain clean compilation to existing targets (such as js_of_ocaml) and new ones (such as webassembly). @kayceesrk is active in the wasm working groups on this topic, and we're using MirageOS (which has compiler forks for esp32 embedded systems) to experiment with overheads using unikernels.
  • ergonomics: and last but not least, the hardest one to answer: once we develop a workable model for typed effects in OCaml, does it work at scale on large codebases and also for writing incremental code that can be locally reasoned about? The only answer to this is to build prototypes of a significant size, which is something we're working on at OCaml Labs as part of efforts like our multicore IO stack. I don't talk about this much at the moment as we regularly thrown prototypes away, but we're converging on some stability in recent months.

To risk an analogy, imagine that we're flying from Cambridge to Fiji for a nice post-pandemic vacation. To get to our end goal, we have to fly via a few intermediate cities (say, London and Sydney). We need to be very careful not to screw up our landing into Sydney because we're so excited about eventually getting to Fiji – if we do that, there is no glorious holiday for us! And you know what? Sydney's not so bad a place to hang out and adjust to jetlag while we carefully plan the flight path to Fiji.

We could really use the community's help with OCaml 5.0, as it's going to be a major release. Rest assured that we're thinking (and working hard) on how concurrency should also show up in OCaml, but it won't happen until we get OCaml 5.0 out of the door. Core OCaml development is all about careful, iterative progress to avoid the risk of losing the properties that make OCaml so reliable for all the downstream projects that depend on us.

Having said all that, I can't wait to get to get to Fiji either. It's going to be an awesome vacation when we finally arrive.

ML Family Workshop 2021: first call for short abstracts and presentations

Jonathan Protzenko announced


The ML family workshop is back, and will be held virtually along with ICFP 2021. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit!

(long version)

We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021.

The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas.

Submission details

Submissions must be at most three pages long; see the full call for papers https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#Call-for-Presentations for details.

Submission site: https://ml21.hotcrp.com/

Important dates

  • Thu, May 27th 2021 (AoE): submission deadline
  • Thu, Jun 17th 2021 (AoE): author notification
  • Thu, Aug 26th: workshop (time slots TBD)

Program committee

  • Danel Ahman (University of Ljubljana)
  • Robert Atkey (University of Strathclyde)
  • Frédéric Bour (Tarides)
  • Ezgi Çiçek (Facebook London)
  • Youyou Cong (Tokyo Institute of Technology)
  • Richard A. Eisenberg (Tweag I/O)
  • Martin Elsman (University of Copenhagen, Denmark)
  • Ohad Kammar (University of Edinburgh)
  • Naoki Kobayashi (University of Tokyo, Japan)
  • Benoît Montagu (Inria)
  • Jonathan Protzenko (Microsoft Research) (Chair)
  • Kristina Sojakova (INRIA Paris)
  • Don Syme (Microsoft)
  • Matías Toro (University of Chile)
  • Katsuhiro Ueno (Tohoku University)

ppx_let_locs - improve stack traces

EduardoRFS announced

A common problem that I personally had when developing async code in OCaml is that both Lwt and Async leads to useless stack traces. When using lwt_ppx that is handled by the ppx, but the same is not possible with let*, let.await or >>=.

If you want to solve that, you can use ppx_let_locs, it will detect your calls and when there is a replacement function available that would allow stack traces to be enhanced it will enhance that by default for you.

How it works

Everytime an ident is applied it tries to find a backtrace_ident or ident_backtrace version of it, if that is present and it has the right signature, the PPX will then apply the backtraced one with the additional argument. This means it also works with operators, like >>=_backtrace, as they're just normal function application.

For letop there is a special case, the signature of the letop must be slightly different to ensure that the typing order was not changed, essentially the let*_backtrace must have the following signature (exn -> exn * 'a) -> 'b -> 'c.

To achieve that this is actually a typed PPX, which runs a slightly patched version of the OCaml typechecker, then untype it and pass to the OCaml compiler. This implies a couple of things:

  • it needs to be executed as (staged_pps ppx_let_locs) on dune
  • versions must be explicitly supported, for now only 4.10 and 4.12 are supported, if you need any other version feel free to request.
  • it can be quite slow on some codebases

To solve the above problems, an important property is that, assuming the backtraced version behaves identically to the non backtraced one, it is in theory a noop, as removing or adding the PPX should not change the behavior of the code. So it can be used only for development or for production, as adding or removing the PPX will not break your code.


Currently it seems like Async doesn't provide anything similar to Lwt.backtrace_bind and Async.try_with also looses the stack trace, so I would love help in this area.






As you can see, on the second stack trace you can find out that it was actually being called on test_interpretation.ml.

Converting typing information from one OCaml version to a later one?

Deep in this thread, EduardoRFS announced

For me reading the cmi is enough, so I implemented it on ocaml-migrate-types, it can do 411 -> 412 types, will implement 410 -> 411, which is probably painful because of the Uid


Set up OCaml 1.1.10

Sora Morimoto announced


  • Run brew update before set up to avoid an issue with Bintray transition period.



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 online.