Previous week Up Next week


Here is the latest Caml Weekly News, for the week of January 17 to 24, 2012.

  1. otags reloaded 3.12.1 for OCaml 3.12.1
  2. ounit v1.1.1: Unit testing framework
  3. polymorphic variants in match statements
  4. Other Caml News

otags reloaded 3.12.1 for OCaml 3.12.1


Hendrik Tews announced:
better late than never: I would like to announce the first
release of otags reloaded for OCaml 3.12. It is available at

Otags reloaded generates tags tables for emacs and vi/vim.

Note that otags (by default) refuses to compile with OCaml
3.12.0, because that version contains a bug that makes otags
quite unusable.

Otags reloaded is distributed under GPL v3.

ounit v1.1.1: Unit testing framework


Sylvain Le Gall announced:
OUnit is a unit testing framework for OCaml, inspired by the JUnit tool for
Java, and the HUnit tool for Haskell.

More information on [HUnit](

In version 1.1.1:

- bracket now enforce returning unit
- update examples
- ListSimpleMake now use the provided comparator for all elements

This version is already available on oasis-db (and can be installed through


Get source code:
$ darcs get

Browse source code:;a=summary

polymorphic variants in match statements


Milan Stanojević asked and Jacques Garrigue replied:
> Hi, we're trying to understand the type inference with polymorphic
> variants in match statements. This is a simplification of an actual
> case that happened in practice.
> 1)
> let f i a =
>  match i, a with
>  | true, `A -> `B
>  | false, x -> x
> fails with
> File "", line 4, characters 16-17:
> Error: This expression has type [< `A ]
>       but an expression was expected of type [> `B ]
>       The first variant type does not allow tag(s) `B
> 2) changing false to _
> let f i a =
>  match i, a with
>  | true, `A -> `B
>  | _, x -> x
> this succeeds with
> val f : bool -> ([> `A | `B ] as 'a) -> 'a
> 3) changing x in (1) to _ , and using a on the right side
> let f i a =
>  match i, a with
>  | true, `A -> `B
>  | false, _ -> a
> this fails in the same way as (1)
> 4) finally adding another case to match statement
> let f i a =
>  match i, a with
>  | true, `A -> `B
>  | false, x -> x
>  | true, x -> x
> this succeeds with the same type as (2)
> So it seems there is some interaction between type inference and
> exhaustivnest of the match statements.
> Can someone shed some light on what is going on here?

Indeed. The basic idea is to close variant types when leaving them
open would make the pattern matching non-exhaustive.
Here, if we assume that a has type [`A | `B], then the pattern-matching
becomes non-exhaustive, so the type inferred is just [`A]
(i.e. the list of all constructors appearing inside the patterns at this 

Actually, the theory is a bit more complicated, and the full details are
in the following paper, but you should just expect the above behavior
in practice.

        Typing deep pattern-matching in presence of polymorphic variants.

Note that there is also another way to make (1) type, without adding
new cases

  let f i a =
    match i, a with
    | true, `A -> `B
    | false, (`A as x) -> x;;
  val f : bool -> [< `A ] -> [> `A | `B ] = <fun>

Here we have removed the connection between a and the output,
allowing `A to be combine with `B without changing the type of a.

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


OCaml Submodule Pattern:

OUnit 1.1.1:

Otags 3.12.1:

A puzzle about typing:

Happy new year from the Ocsigen team:

1D integration:

Share your mistakes: adventures in optimization:

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