Previous week Up Next week


Here is the latest Caml Weekly News, for the week of October 30 to November 06, 2012.

  1. Why should I use .mli files?
  2. Functional programming users group in Cambridge, UK (free beer!)
  3. Writing the function using first-class modules and 4.00 inference
  4. Bisect 1.3 release
  5. OCaml interpreter in JavaScript
  6. Other Caml News

Why should I use .mli files?


Deep in this thread, Jacques Garrigue explained:
I see that a big debate is going on mli files and declarations
inside ml files.

I think that lots of people have given this problem a lot of thought
during many years.
My conclusion has unfortunately been that trying to solve this at
the language level without breaking backward compatibility is
very difficult.

For instance, one is currently allowed to do something like that:
let f x = x

let b = f true

val f: int -> int

This may look stupid, but this kind of code (of course more
complicated) exists in the wild, and sometimes for sensible
For this kind of reason, I do not see any easy way to import
information from mli files to ml files.

Now, is maintaining mli files really painful?
In my experience, not at all.
Taking as example the ocaml compiler itself, the only
duplication that bothers me a little is the error type exported
by many modules, as one always has to keep it in sync by
copy-paste. This is a bit of a problem because for most uses
this type could be abstract (you don't really care about its
contents), but in some rare occasions you need it public.
For other types, do not see syncing as a disadvantage, because
it rather makes you conscious that other modules depend on
this type, so better look at it twice :-)

Of course I know that some people (probably with a different
background) do not like mli files.
Couldn't we just imagine a preprocessing tool that allows to
generate both ml and mli from the same file?
This is pretty standard for literate programming.
It could even call the compiler if you want the types to be inferred
automatically (even though I personally think that having to write
value types in the mli file is good, because you know when you
are changing an export.)
As an external tool, it could use pragmas (keywords inside
comments) for instance.
Something close to ocamldoc (ocamldoc itself?) but which you
would integrate in the compilation cycle.

Anyway, I just wanted to state, from my experience, my lack of
enthusiasm about modifying the core language to accommodate

Functional programming users group in Cambridge, UK (free beer!)


Mike McClurg announced:
We're starting a functional programming group in Cambridge, UK, called
NonDysFunctional. We're having our first meet up this Friday from 5pm
to 9pm at the Old Spring Pub. Feel free to come at any time during
that window. Citrix has kindly offered to pay for everyone's beer, so
come thirsty!

See our website for more information, including a map to the Old

Also, we will be tweeting about future events on @nondysfun

If you think you might come, please email me, just so I have an idea
of how many people might turn up. You don't have to register in order
to come, however. Hope to see you there!
He later added:
We had a successful meeting last Friday for our first Cambridge
functional programmers meetup. As requested by those who turned up,
I've created a meetup group to help us organize. If you are
interested, please join here:

We're probably going to have another meeting in early December. It
will probably just be another pub meetup. If you've got any requests
for dates or for particular pubs, please let me know.

Now that we've got an online home at, I'll avoid spamming
this list with future announcements.

Writing the function using first-class modules and 4.00 inference


Jeff Meister said:
I found an interesting (to me, anyway) use of OCaml's first-class
modules, and particularly the new 4.00 type inference features, which
I thought was worth sharing with the list. This has probably been
observed by someone else already, but I haven't seen it discussed.

In the OCaml standard library, the polymorphic set data structure is
implemented as a functor, which takes a module containing a type t and
total ordering function over t, and returns a module representing sets
whose elements have type t. Like so:

module StringSet = Set.Make(String)
module CharSet = Set.Make(Char)

One disadvantage of this method is that once the functor has been
called, the type of the set elements is fixed. As a consequence,
OCaml's set interface has no map function. If we had a polymorphic
type like 'a set, this function would have type 'a set -> ('a -> 'b)
-> 'b set. But StringSet.t and CharSet.t are not polymorphic; the
corresponding type elt in each module cannot be changed.

However, using first-class modules, we can write a function map for
sets, which takes as an extra argument the packaged module
representing the set we're mapping from. Maybe this function is better
called map_from. Check it out:

# module Set = struct
    module type OrderedType = Set.OrderedType
    module type S = Set.S
    module Make(Ord : OrderedType) = struct
      include Set.Make(Ord)
      let map (type e') (type t') (module OtherSet : S with type elt = e' and type t = t') os f =
       OtherSet.fold (fun x accu -> add (f x) accu) os empty
[... bunch of output ...]
val map :
  (module S with type elt = 'a and type t = 'b) ->
  'b -> ('a -> elt) -> t

Now, back in OCaml 3.12, this function could be written (without the
nice package-expanding pattern I've made use of), but calling it was
quite a pain, enough to invalidate the whole enterprise. One would
have to type this:

# let strs = StringSet.(add "foo" (add "bar" empty));;
val strs : StringSet.t = <abstr>
# let chrs = (module StringSet : Set.S with type elt = StringSet.elt and type t = StringSet.t) strs (fun s -> s.[0]);;
val chrs : CharSet.t = <abstr>

It's much easier with the type inference changes in OCaml 4.00:

# let strs = StringSet.(add "foo" (add "bar" empty));;
val strs : StringSet.t = <abstr>
# let chrs = (module StringSet) strs (fun s -> s.[0]);;
val chrs : CharSet.t = <abstr>

Bisect 1.3 release


Xavier Clerc announced:
This post announces the 1.3 release of the Bisect project, whose goal
is to provide a code coverage tool for the OCaml language.

Home page:

Main changes since 1.2:
- new instrumenter based on '-ppx'
- new '-summary-only' to output only summary (text mode only)
- refactoring, including minor bugfixes
- bug#86: '-ocaml-prefix' doesn't really work
- bug#87: install shouldn't build anything
- bug#89: do not activate warnings by default

OCaml interpreter in JavaScript


Diego Olivier Fernandez Pons asked and Fabrice Le Fessant replied:
> Last time I was looking for a JavaScript interpreter in Caml. Now I
> need a Core ML interpreter written in JavaScript to run source OCaml
> code on a browser, similar to Skulpt one in Python

Have you tested ? It is the ocaml toplevel,
compiled with js_of_ocaml, so executing ocaml sources in a browser.
The sources are available on GitHub from the link.

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at


Bisect: 1.3:

Dropbox-as-a-Database, the tutorial:


Generic Graphml Printer for OcamlGraph:

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