OCaml Weekly News

Previous Week Up Next Week


Here is the latest OCaml Weekly News, for the week of October 20 to 27, 2020.

Table of Contents

Bisect_ppx, the coverage tool, now has excellent integration with Dune

Anton Bachin announced

Bisect_ppx, the coverage tool, has just had its 2.5.0 release, in which the main addition is a very neat integration with Dune:

dune runtest --instrument-with bisect_ppx --force

This uses the new instrumentation support added in Dune 2.7.0, and is a considerable improvement over the dubious methods Bisect and its users were previously forced to rely on :)

It is no longer necessary to edit dune files for a release, as Bisect only becomes a dependency of your project when --instrument-with bisect_ppx is supplied on the Dune command line, which is only during development and in CI. This makes projects ready for release from any commit. Dune also now knows to rebuild affected files when instrumentation is turned on or off, so you don't have to manually run dune clean in between. Everything just works the way it should.

See the updated instructions for all the details on how to use this integration.

I've also adapted Lambda Soup as a simple full-project example. See its opam, dune-project, dune, and Makefile.

Bisect_ppx still supports all the older integrations, so if you have an existing setup, you don't have to edit it. Support may eventually be removed in the future, however, so I encourage users to gradually update.

See the full changelog for information on bugs fixed by the release.

Thanks to the Dune team for adding --instrument-with, to @undu for supporting it on the Bisect side, and to all the Bisect_ppx users and contributors!

Happy testing!



Js_of_ocaml in the VSCode OCaml Platform

Max LANTAS announced

I just finished a write-up about vscode-ocaml-platform's recent transition to Js_of_ocaml: https://mnxn.github.io/blog/ocaml/vscode-jsoo/

I can answer any questions here.

This is also my first technical blog post, so any constructive criticism or comments about my writing would be very helpful.

Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)

Laurène Gibaud announced

At OCamlPro, we will be organizing 2 cross-company training sessions in French. Both sessions interleave theory and practice. You'll have time to ask your specific questions and get personalized feedback on your programs.

  • Our Beginner session will allow developers to build upon their experience of other programming languages (such as C, C++, Python, C# or Java) to program confidently in OCaml. Feel free to share the info with your coworkers or your network!
  • Our “Expert OCaml” training will allow you to master OCaml’s advanced features such as its type-system, OCaml’s open source tools and libraries, and how to write compact and efficient code.

More info on the program and prerequisites on http://www.ocamlpro.com/training-ocamlpro/ or ask away (answer this email or write at contact@ocamlpro.com).

When? The Beginner session is scheduled for November 23-24, 2020. The Expert session will be on November 25-26, 2020.

Where? Paris 14, in OCamlPro's office.

How? Register on: https://www.ocamlpro.com/pre-inscription-a-une-session-de-formation-inter-entreprises/

We can also organize custom and on-site sessions upon request.

Set up OCaml 1.1.2

Sora Morimoto announced

This release contains these changes:

  • Add the Cygwin setup to a known location for later steps
  • Check if the switch exists before creating the switch


Set up OCaml 1.1.3

Sora Morimoto announced

This release contains these changes:


First release of FSML

jserot announced

This is to announce the first public release of FSML, an OCaml library for describing and describing synchronous finite state machines.

FSML is a simplified version of the library provided in the Rfsm package for which

  • the system is composed of a single FSM
  • this FSM has a single, implicit, triggering event (typically called the clock , hence the term synchronous used in the description)

The FSML library provides

  • a type Fsm.t for describing FSMs
    • possibly having local variables
    • for which transitions , implicitely triggered by a clock, are defined by a set of boolean guards and a set of actions
  • a set of PPX extensions for building values of type Fsm.t
  • functions for producing and viewing graphical representations of FSMs in the .dot format
  • functions for saving and reading FSM representations in files using the JSON format
  • functions for performing single or multi-step simulations of FSMs and generating trace files in the .vcd format to be viewed by VCD viewers such as gtkwave
  • functions for generating C or VHDL code from a FSM representation (for integration into existing

code and/or simulation)

FSML is available from Github or as an OPAM package.

Qrc 0.1.0, a QR code encoder

Daniel Bünzli announced

QR codes are unsightly – a mirror of their specification. But they enable all sorts of neat tricks now that scanners for them are in many pockets.

Qrc generate them:

Qrc encodes your data into QR codes. It has built-in QR matrix renderers for SVG, ANSI terminal and text.

Qrc is distributed under the ISC license. It has no dependencies.

Homepage: https://erratique.ch/software/qrc
API docs: https://erratique.ch/software/qrc/doc/ or odig doc qrc
Install: opam install qrc

cumulus 0.0.1

Petter A. Urkedal announced

I would like to announce a new FRP library built on the React library. The purpose of cumulus is to help organize code which work on differential updates. The main type is the cumulus signal, which is analogous to a react signal, except that information about the difference from the previous value is provided to consumers along with the new value, when the cumulus signal changes.

So, why does a cumulus signal provide both the state and the difference to downstream signals? That is, what is the difference between the following:?

type t1 = state * change React.E     (* initial value and even of changes *)
type t2 = (state, change) Cumulus.t  (* the cumulus signal *)

The former type presumes that after the consumer has received the initial state, it will only need to know what changes on successive updates. This seems quite natural. It works well if, for instance, we want to reconstruct a signal holding a set of strings, given an initial set and a series of additions and removals:

module String_set = Set.Make (String)

type 'a set_patch = [`Add of string | `Remove of string]
type 'a update = 'a -> 'a

let patch_string_set : string set_patch -> String_set.t update = function
 | `Add x -> String_set.add x
 | `Remove x -> String_set.remove x

let integrate_strings (init, changes) =
  React.E.fold (fun l p -> patch_string_set p l) init changes

But what if we want to maintain a signal holding the intersection of two sets of strings? If we try to lift the intersection operation to work on patches, we discover that learning about the addition of an element to left-hand set is not sufficient to determine whether the element shall the added to the resulting set; we also need to know whether the element is a member of the right-hand set. So, in this case we would instead use cumulus signals:

let cu : (String_set.t, string set_patch) Cumulus.t = ...
let cv : (String_set.t, string set_patch) Cumulus.t = ...
let cuv =
  let init u v = String_set.inter u v in
  let patch (u, du) (v, dv) r' =
    (match du, dv with
     | None, Some x when String_set.mem x u ->
        Cumulus.Patch (String_set.add x r', `Add1 x)
  Cumulus.l2 ~init ~patch cu cv

For the complete example, using integers instead of strings, see test_isecn.ml from the testsuite.

(Footnote: If consumers know how to integrate the states they depend on, they could in principle keep their own record of the full states of the arguments. But this would be inefficient if there are many consumers, and there is also a simplification of code and possibly improved abstraction in letting the producer maintain its own state.)

Formally, we can understand the difference between t1 and t2 in terms of calculus. For instance, the differential of a product d(x·y) = dx·y + x·dy contains a mix of both the differentials and values of the two variables. But if the expression is linear, only differentials will will occur: d(a·x + b·y + c) = a·dx + b·dy. So, when t1 is sufficient, we are dealing with the analogue of a linear function. The above example could be turned into a linear one by making Labels.t a multiset type and considering the multiset union operation.

Thus far we only considered purely functional code, but a cumulus signal may chose to modify and return the same physical state during an update. Also note when designing the differential component of the cumulus signal, that we may exploit the fact the consumers also may inspect the corresponding new state. Combining these two points, a cumulus signal holding an array might have the type ('a array, [`Set of int | `Resize of int]). Here the state may be reused for `Set and replaced for `Resize.

On a related not, there is also the reactiveData library which deals with (linear) patching of containers.

I must also mention that there there is an OCaml project with the same name (except casing). Sorry for not checking thoroughly in advance. I hope it is not an issue in practise, otherwise there is still time to rename while the library is fresh.

Brr 0.0.1, a toolkit for programming browsers

Continuing this thread, Yoann Padioleau asked Daniel Bünzli replied

What are the differences with the default bindings provided in js_of_ocaml to the browser APIs (e.g., js.mli, dom.mli, etc.)?

I'm not sure exactly what you are asking but:

  1. If you are asking about the way API are exposed: brr does not type JavaScript's objects as phantom types. It simply relies on OCaml's abstract data types and plain functions. More about this can be found in brr's FFI manual and FFI cookbook.
  2. If you are asking about binding coverage, you should be able to get a sense of what is bound in brr here.

Regarding 2. brr's coverage of more recent browser APIs is broader and more consistent than in js_of_ocaml – Promise support, Fetch, Service workers, Media capture APIs, WebGL2, Webcrypto, WebAudio, etc. Conversly older APIs supported in js_of_ocaml may not supported in brr (e.g. XMLHTTPRequest). Besides brr's coverage of some of the DOM element-specific interfaces may be shallower than in js_of_ocaml. There is however good coverage for the HTMLMediaElement, HTMLCanvasElement, HTMLFormElement and HTMLInputElement interfaces. For the rest the attribute and property API and the occasional trivial FFI method binding should be able to get you a long way.


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.