Previous week Up Next week


Here is the latest OCaml Weekly News, for the week of February 07 to 14, 2017.

  1. 2015 ML & OCaml post-proceedings now available
  2. parallpairs
  3. Opam 2.0.0~beta is out!
  4. Ocsigen Start and Ocsigen Toolkit: Quick Web and mobile app in OCaml
  5. namespace inside object?
  6. first official release of Hoogle for OCaml programmers
  7. release of containers-1.0
  8. BuckleScript 1.4.3 - Link time dead code elimination
  9. Next OUPS meetup, Feb. 21th 2017
  10. Ocaml Github Pull Requests
  11. Other OCaml News

2015 ML & OCaml post-proceedings now available


Jeremy Yallop announced:
Readers of caml-list may be interested to know that the joint
post-proceedings of the 2015 ML and OCaml workshops have now been

Of the four papers in the volume, three are directly relevant to OCaml users:

   * Generating Code with Polymorphic let: A Ballad of Value
Restriction, Copying and Sharing (Oleg Kiselyov) describes a
translation from a MetaOCaml-style multi-staged language into a
language without staging, with support for generating polymorphic-let

   * GADTs and Exhaustiveness: Looking for the Impossible (Jacques
Garrigue and Jacques Le Normand) explores the difficulties with
checking pattern-matching exhaustiveness for GADTs in the presence of
abstract types.  The paper includes details of the "refutation
patterns" introduced in OCaml 4.03.

   * Specialization of Generic Array Accesses After Inlining (Ryohei
Tokuda, Eijiro Sumii and Akinori Abe) describes an optimization in the
OCaml compiler that extends the intermediate language with array type
information to avoid runtime type dispatch.

and the fourth falls within the broader area of ML-family languages:

   * Dependent Types for Multi-Rate Data Flows in Synchronous
Programming (William Blair and Hongwei Xi) describes an implementation
of the synchronous programming language Prelude using the type system
of the ML-family language ATS.

With kind regards,

Damien Doligez
Jeremy Yallop (editors)



Eray Ozkural announced:

Parallel all-pairs similarity search algorithms in OCaml

If you use this code, please cite the following paper. It is currently under
review at IJPP.

1-D and 2-D Parallel Algorithms for All-Pairs Similarity Problem

Eray Özkural, Cevdet Aykanat (Submitted on 13 Feb 2014)

All-pairs similarity problem asks to find all vector pairs in a set of vectors
the similarities of which surpass a given similarity threshold, and it is a
computational kernel in data mining and information retrieval for several tasks.
We investigate the parallelization of a recent fast sequential algorithm. We
propose effective 1-D and 2-D data distribution strategies that preserve the
essential optimizations in the fast algorithm. 1-D parallel algorithms
distribute either dimensions or vectors, whereas the 2-D parallel algorithm
distributes data both ways. Additional contributions to the 1-D vertical
distribution include a local pruning strategy to reduce the number of
candidates, a recursive pruning algorithm, and block processing to reduce
imbalance. The parallel algorithms were programmed in OCaml which affords much
convenience. Our experiments indicate that the performance depends on the
dataset, therefore a variety of parallelizations is useful.

The code is quite interesting, as it shows how to effectively use OCaml for MPI
code. There is a bunch of well-written parallel functional code that I will
extract from this codebase and release separately. You need the latest ocamlmpi
release as that contains the patches I made to make this code work.

This code is released under AGPL-3.0. Please do not ask me to release it under
BSD license. If you need a commercial license, you should purchase it.

Happy hacking!

Opam 2.0.0~beta is out!


Louis Gesbert announced:
We are please to announce that the beta of Opam 2.0.0 is out!

You can read the full announcement here:

Highlights of the beta, as compared to the previous alpha version, include:

- The new 'opam build' command, to compile source trees directly
- Support for repository signing through the external Conex¹ tool

Please try it out, and let us have feedback!

Ocsigen Start and Ocsigen Toolkit: Quick Web and mobile app in OCaml


Vincent Balat announced:
The Ocsigen team is very happy to announce the first release of two new major

- Ocsigen Start: a Web/mobile application skeleton written with Js_of_ocaml and
Eliom, that you can use as a basis for your own app or to learn Web/mobile app
programming in OCaml,

- Ocsigen Toolkit: a set of responsive widgets for your mobile and Web
applications in OCaml.

Both projects are available on Opam and released under LGPL.

Before installing, you can test an online version of Ocsigen Start here: The demo application for Android is
available in Google Play store: If you prefer,
you can install it manually using the apk file: iOS version is also available
here: (to be installed via

Ocsigen Start provides the basic features for user management (registration,
activation links, password recovery, etc), and some useful libraries. Remove the
parts you don't need for your own app.

Ocsigen Start also contains many examples of code: remote procedure calls, push
notifications from server, reactive pages, database interaction, session data,
internationalisation, and some widgets from Ocsigen Toolkit.

Ocsigen Toolkit contains common widgets for mobile and Web apps, written
natively in OCaml and specifically designed for Eliom's multi-tier and
multi-platform programming style. You can also use them in client-only
Js_of_ocaml programs. Many new widgets will be added in future versions.

Ocsigen Start and Ocsigen Toolkit are developed by the Ocsigen team at Be Sport
and Univ. Paris Diderot/IRILL.

namespace inside object?


Steffen Smolka asked:
Is it possible to create namespaces inside an object? Concretely, I would like
to write

class buffer = object(self)
method get = ...
module Latin1 = struct
method get = ...

module Utf8 = struct
method get = ...

so that given an object b : buffer, I can call methods

Declaring modules inside an object seems to be illegal, though. Is there any way
to achieve something along those lines? Is there a better way to structure
Jeremy Yallop replied:
It's possible to achieve something like this using methods that return
objects.  If your nested objects don't need to access the internal
state of the parent then you might write it like this:

  class buffer =
    let latin1 = object
      method get = ...
   and utf8 = object
      method get = ...
   end in
     method get = ...
     method latin1 = latin1
     method utf8 = utf8

With this approach you can write


which, apart from some minor orthographic differences, looks like what
you were aiming for.

Your intuition that this isn't really idiomatic OCaml is right,
though.  In OCaml, unlike some other languages with classes and
objects, classes are not usually used as namespaces; method names are
globally (or, rather, "ambiently") scoped, and there's no real support
for the kind of nesting that you're interested in.  Instead, people
typically build nested namespaces using modules:

  module Buffer =
     let get = ...

     module Latin1 = struct
        let get = ...

     module Utf8 = struct
        let get = ...

With the module approach you write the 'receiver' after the 'method'
rather than before, but that doesn't seem like a huge hardship.  (10%
of the world manages to get by with VSO languages.)

  Buffer.get b ...
  Buffer.Latin1.get b ...
  Buffer.Utf8.get b ...

If you're keen to stick with objects there are slightly more idiomatic
ways to make it work.  You could, of course, replace the '.' with a
'_' and define methods 'latin1_get', 'utf8_get' in place of
'Latin1.get', 'Utf8.get'.  Or you could select the encoding using a
variant type:

  type enc = Latin1 | Utf8

  class buffer =
  object (self)
     method get = function
         | Latin1 -> ...
         | Utf8 -> ...

Of course, the order of the words in an invocation changes again, but
there's no real increase in complexity for the caller:

  b#get Latin1
  b#get Utf8

This last approach can be taken quite far -- for example, you could
enrich the type 'enc' so that the return type of 'get' varies
according to the encoding.
Steffen Smolka then said:
Thanks for the detailed answer, Jeremy!

> If you're keen to stick with objects

Yes, I rely on inheritance and dynamic dispatch for what I have in mind. (This
is actually the first time I'm touching the dark object oriented side of OCaml
:) )

To give some more context, I am refactoring some code that uses modules and no
objects. The reason I want to move to objects is that I want to derive a
slightly enhanced module from some base implementation. Inheritance + dynamic
dispatch allow me to do so with very little trouble: I can simply overwrite a
few methods from the base implementation.

I suppose I could achieve the same by turning the base module into a functor,
and abstracting over the functions that my enhanced implementation needs to
replace. I think it won't be quite as natural, but I'll give that a try.

> Or you could select the encoding using a variant type:

Good idea, and I'm happy with the syntax for the caller. But I'm more concerned
with the organization of the code; this would mix the Latin1 and Utf8
implementations. I would rather keep them separate.
Gerd Stolpmann then said:
First-class modules could also be an option: Let's assume both the base module
and the modified one can use the same module type:

module T = sig ... end

Now, define the base module like

module Base : T =

then, define the modified one:

module Mod : T =
include Base
... now override what you need to change but note that there's no dynamic dispatch ...

Of course, you could also use functors for making these modules.

Now turn this into first-class modules and pass them around:

let base = (module Base : T)
let mod = (module Mod : T)

The syntax for unpacking the module is quite cumbersome:

let module M = (val base : T) in
M.function ...

Unfortunately, there's nothing simple like base.function.

Compared with objects you get:

* You can also put types and (to some degree) modules into these "code
* However, there's no dynamic dispatch except you arrange explicitly for that,
e.g. with references to functions
* Generally, a heavier syntax, but it might be ok
Steffen Smolka then said Yaron Minsky replied:
> Yeah, I have seen that there is support for first class modules, that's
> pretty cool stuff!
> I do need dynamic dispatch, though.

I've always been a bit confused about what the term "dynamic dispatch"
means, but don't first class modules provide what you want? After all,
when you write:

let f (module M : S) x =
    M.g x

the specific function M.g is determined dynamically, depending on
which first class module is passed into f.
Steffen Smolka replied:
Right....but you have to explicitly make that choice when you implement `f`.
With objects on the other hand, somebody may write a base implementation c:

class c = object(this)
method foo = ... this#bar ...
method bar = ... this#foo ... (* original definition *)

Later on, somebody else may refine this implementation by overwriting c#bar:

class c2 = object(this)
inherit c
method bar = ... (* new definition *)

Now c2#foo will invoke the new definition of bar, even though the author of `c`
may have never anticipated this (and did not have to account for this
possibility when he defined foo).

So, I would say "dynamic dispatch" plus inheritance give you the ability to
extend modules in ways that weren't necessarily anticipated by the original
author of the module. And yet all the code written by the original author will
work with your extended version of the module.
Yaron Minsky then remarked:
Sure. And if that's what you want, objects seem like the right solution.

That said, I find this style hard to think about, since it involves
breaking ordinary notions of abstraction. The more explicit style
where you use functors (or functions, if using first class modules) to
parameterize code feels cleaner and easier to reason about to, though
it does have some more syntactic overhead.
Leo White also remarked:
I think it would be more correct to say that you want open recursion. Classes
are the easiest way to get that in OCaml, and they indeed use dynamic dispatch
and inheritance, but there are other mechanisms that provide open recursion. For
example, most proposals for "mixin modules" support open recursion but I
wouldn't say they use dynamic dispatch.
Evgeny Roubinchtein then asked and Markus Mottl replied:
> Apologies in advance for my ignorance, but is there some reference(s) you
> could point me to where the notion of "open recursion" is defined?  I am
> pretty sure I understand "dynamic dispatch."

Lets first see what closed recursion typically looks like:

  type t = Num of int | Add of t * t
  let rec eval = function Num n -> n | Add (x, y) -> eval x + eval y

This type cannot be extended recursively with another operation, say
"Sub" for subtraction, because "Add" only takes arguments of type "t",
i.e. it only permits "Num" and "Add" under itself.

If you want to permit extensibility, you have to "break" the
recursion, leaving it open.  This can be done by introducing a type
variable that captures extensions to the datastructure, and an extra
evaluation function argument to "eval" to deal with the evaluation of

Polymorphic variants make implementations of open recursion much more
elegant than regular variants.  You can check out a simple example for
the above problem here:
Leo White also replied:
A google search will probably produce some reasonable definitions, but for a
more precise treatment I think you can look in Chapter 18 of "Types and
Programming Languages".

first official release of Hoogle for OCaml programmers


Francois Berenger announced:
I am pleased to announce the very first official release of
Hoogle for OCaml programmers.

The project page is here:

The tarball is here:

release of containers-1.0


Simon Cruanes announced:
It is my great pleasure to announce the release of Containers 1.0, after
almost four years of development. Containers is a modular, clean and
powerful extension of the OCaml standard library, under the permissive
BSD license.

It is designed to be efficient, light on link-time dependencies, and to
complement the existing modules rather than replacing them.
The core library has no dependency on unix and should be usable
everywhere. Every module is independent and is prefixed with 'CC' in
the global namespace.  Alternatively, `open Containers` will bring
enhanced versions of the standard modules into scope, along with a few
modules that should exist, such as Option, IO or Int.
Containers now requires OCaml >= 4.01.

Containers also features sub-libraries for helping with threads,
S-expressions, and some unix utilities to invoke sub-processes.

I jump on the opportunity to thank the various users and contributors
that helped improving the code, kept asking for better solutions, and
reported bugs.


github page:
overview of 1.0:

BuckleScript 1.4.3 - Link time dead code elimination


Hongbo Zhang announced:
BuckleScript is an optimizing compiler for OCaml to generate readable
JavaScript, it is open sourced by Bloomberg [1].
We are glad to announce 1.4.3, this release brings JS native module support to
BuckleScript. In combination of existing JS bundler like rollup, it generates
very small JS code output, below is an example:
Js.log (List.length [1;2;3])

test.js -- comments removed
import * as List from "../lib/es6/list"
console.log(List.length ([1,[2,[3,0]]]))

test.bundle.js --comments removed
(function (){
var invalid_argument = [ "Invalid_argument", -3];
function length(l) {
var _len = 0;
var _param = l;
while(true) {
var param = _param;
var len = _len;
if (param) {
_param = param[1];
_len = len + 1 | 0;
continue ; 
else {
return len;

Documentation is available here:

To install:
npm install -g bs-platform

Happy hacking in OCaml! -- Hongbo

Next OUPS meetup, Feb. 21th 2017


Bruno Bernardo announced:
The first OUPS meetup of 2017 will take place on Tuesday, Feb. 21, 7pm
at IRILL on the Jussieu campus.
As usual, we will have a few talks, followed by pizzas and drinks.

The talks will be the following:

- Jacques Garrigue on GADTs and missing cases : searching for the impossible
- Vincent Balat on Ocsigen Start : Quick web and mobile apps in OCaml
- Benoit Rognier on Edukera : a web app for teaching maths.

Please do note that we are always in demand of talk *proposals* for future

To register, or for more information, go here:

*Registration is required! Access is not guaranteed after 7pm if
you're not registered.* (It also helps us ordering the right amount of

Slides from previous sessions are available online:

Access map:
IRILL - Université Pierre et Marie Curie (Paris VI)
Barre 15-16 1er étage
4 Place Jussieu
75005 Paris
The meetup organizers.

Ocaml Github Pull Requests

Gabriel Scherer and the editor compiled this list:
Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.

- Adding a new field to record `formatter_out_functions` to redefine the meaning
of indentation
- Symbolic formatted pretty-printing
- User-defined indexing operator without array indexing
- API changes for multicore
- Merge Unix and Windows build systems in the root directory
- Implemented `List.init`
- Improve tools/read_cmt
- PR#7478: ocamldoc, avoid module preambule repetion

Other OCaml News

From the ocamlcore planet blog:
Here are links from many OCaml blogs aggregated at OCaml Planet,

Ocsigen Start and Ocsigen Toolkit reach 1.0!

opam 2.0 Beta is out!

Old cwn

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.

Alan Schmitt