Previous week Up Next week


Here is the latest Caml Weekly News, for the week of March 06 to 13, 2012.

  1. TypeRex release 1.0.0 candidate 1
  2. OCaml Users and Developers workshop (OUD)
  3. oasis packaging questions
  4. A js_of_ocaml equivalent for the JVM?
  5. Stog: static web site and blog generator
  6. TypeRex 1.0.0
  7. ocamldoc: Howto crossreference another library?
  8. Other Caml News

TypeRex release 1.0.0 candidate 1


Continuing the thread from last week, Stefano Zacchiroli asked and Tiphaine Turpin replied:
> At the same time, I'm not thrilled at the idea of having to use a
> different ocamlc just to benefit from TypeRex. Having to do so brings a
> number of disadvantages, the first and foremost being that now the
> programmer needs to worry about having synchronized versions of the
> "legacy" ocamlc installed on his machine and the version shipped by
> TypeRex.
First, a small precision (which may not be obvious from TypeRex 
documentation): as the ocp-ocamlc, ... commands are only wrappers, they 
are not tied to a particular version of the actual compilers they call. 
In fact the following three components are somehow independent:
- the installed OCaml compilers (currently only 3.12.* is supported, 
because by mistake we forgot to include 3.11 compatibility, will be 
fixed in 1.0.0)
- TypeRex (with ocp-type and ocp-ocamlc, etc.)
- the OCaml compiler used to compile TypeRex (since rc2, >=3.11 works)
However, TypeRex won't be able to handle new language constructs that 
are introduced in OCaml after we extract its front-end, which implies that:
- we will have too follow closely the language evolutions and we will 
release a new version of TypeRex for each major release of OCaml.
- using Typerex for developping the OCaml compiler prevents you to use 
the new language constructs that you introduce, until TypeRex is itself 
>   But there are more disadvantages, unfortunately.
> Can you tell us why we can't (or maybe *when* we will be able to :-))
> have the nice features offered by TypeRex on top of the stock ocamlc
> compiler?
We would like to have the binary annotation feature included in the next 
release of OCaml. Before proposing a patch upstream, we wanted to 
stabilize the changes in the compiler and prove them to be generic 
enough. But there are two alternatives to having binary annotations in 
- improve the ease of use of the wrappers (there have been interesting 
suggestions in this direction on the issue tracker)
- integrate with a build system (which would also replace the ad-hoc 
.typerex file)

OCaml Users and Developers workshop (OUD)


Didier Remy announced:
                            OUD 2012
                     CALL FOR PRESENTATIONS
                       Copenhagen, Denmark
                           Fri, Sep 14th
                      Co-located with ICFP 2012
                        Sponsored by SIGPLAN
            Talk Proposal Submission Deadline 8th June 2012

In 2012, the OCaml Meeting will be renamed the OCaml Users and Developers
workshop (OUD), and be colocated with ICFP in Copenhagen, Denmark. It
will be held on Friday September 14, after the ML workshop (Thu 13)
and before the Commercial Users of Functional Programming (Sat 15).

The OCaml Users and Developers Workshop will bring together industrial
users of OCaml with academics and hackers who are working on extending the
language, type system and tools. Discussion will focus on the practical
aspects of OCaml programming and the nitty gritty of the tool-chain and
upcoming improvements and changes.  Thus, we aim to solicit talks on
all aspects related to improving the use or development of the language,
including, for example:

- compiler developments; new backends, runtime and architectures.
- practical type system improvements, such as (but not exhaustively)
  GADTs, first-class modules, generic programming, or dependent types.
- new library or application releases, and their design rationales.
- tool enhancements by commercial consultants.
- prominent industrial uses of OCaml, or deployments in unusual

It will be an informal meeting, with an online scribe report of the
meeting, but no formal proceedings for this year. Slides of presentations
will be available online from the workshop homepage.

To submit a talk, please register an abstract or outline (1-2 pages) at with as much information as you feel will
support the proposal.  If you wish to perform a demo or require any
special setup, we will do our best to accommodate you.


Abstract Submission Deadline: Friday, 8th June 2012
Notification to Speakers: Friday, 6th July 2012
Workshop: Fri, 14th September 2012

Program Committee

* Didier Remy (co-chair)
* Anil Madhavapeddy (co-chair)
* Alain Frisch
* Jacques Garrigue
* Thomas Gazagnaire
* Martin Jambon
* Richard Jones

If you have any questions, please e-mail:
Didier Remy 
<didier.remy AT>
Anil Madhavapeddy 
<avsm2 AT>

oasis packaging questions


Daniel Bünzli asked and Sylvain Le Gall replied, spawning a large thread:
> I'd like to support oasis in the various packages I distribute. Here are a 
> few questions (using oasis v0.3.2~rc2). 
> 1) All the packages I distribute are made of a single module. For now these 
> were just installed as .cmo .cmx .cmxs. Now it seems oasis forces me to 
> create a .mllib even if I have only one module. Is that correct ? 

For now yes, but I plan to support only object through an Object
section, just like the Library:

> 2) Will the change in 1) have any impact for downstream packagers and is 
> enough for them ? 

The main change of .cmo -> .cma is that toplevel expression are only
evaluated if you open the module. This can be a problem if your .cmo are
used in a plugin way (i.e. toplevel expression register the content of
your library) and that you don't open it. will be enough for me ;-) But I am biased.

> 3) The META plugin doesn't seem to generate the directives for plugins [1], 
> is that right ? Does support cmxs generation at all ? 

We don't support plugin, indeed. Mostly because I was not aware of it. doesn't yet support .cmxs. I was looking at a patch provided by
Pierre Chambart yesterday evening to do that. Will probably be in 0.3.

> 4) I'm really not interested in oasis trying to generate my _tags and 
> files. Is it ok to substitute my own or does rely 
> on these ? 

You can substitute your own. There should be no problem. Don't hesitate
to open a feature request to explain the reason why and your solution. I
don't promise it will be implemented, but it is worth understanding the

> 5) One of the disadvantages of things like odb is that you may miss 
> valuable information like a CHANGES file, proper documentation or sample 
> programs. These are also things you actually would like to remove when you 
> do a ocamlfind remove. Is there any general agreed on strategy for packages 
> ? Best I think would be to install that along in the package directory with 
> ocamlfind, it makes it relatively easy/evident to lookup. 

We already discuss this CHANGES file stuff. I still didn't have the time
to work on that, but it is something that I want. In future version
there should be something like that.

Use 'PostCleanCommand: rm XYZ'

DataFiles should do that. Concerning installing this using ocamlfind, I
am a little more skeptical. We use standard cp to install in
/usr/share/doc. I don't know a lot of libraries that install their
documentation in /usr/lib, probably because there are packaging rules
against that.

> 6) Regarding 5) I tried to define documentation as follows : 
> Document xmlm
> Title: "Xmlm documentation and module reference"
> Format: html
> Index: Xmlm.html 
> Install: true
> InstallDir: $htmldir/xmlm
> DataFiles: README CHANGES doc/*.html, doc/*.css
> but ocaml setup -install doesn't seem to install it. Of course this is also 
> certainly a wrong strategy since it would install it in some directory that 
> wouldn't be removed by ocamlfind remove. So how do we achieve that ? 

I think the default Type: for document is None, which means do nothing.
You can use "Type: Custom" and have a "XCustomInstall: cp XYZ

I realize that this no good. I probably should code a plugin Static, to
have "Type: Static" and use the data you fill in Document section to
install. This is not a long job.

Could you open a bug about that, so that it will remind me to do it ?

> 7) ocaml setup -install seems to install the modules' .mli, .cmi and .cmx 
> by finding them in _build capitalizing the filenames even though they are 
> not (cf. [2]). That works on my case insensitive filesystem, but it mustn't 
> work on others, the original files are not capitalized !? Is that a bug ? 

That is a bug. I have similar problem with the Pack: when generating
_tags with capitalized module name. I installed ocaml on a mac yesterday
to find the right solution. It will be shipped with oais 0.3.0~rc3. But
this part of the bug is not extremly important, because on case
sensitive FS, it will replace the capitalize module name by the right
name. It is a runtime evaluation so no worries on this point.

> [1] 
> [2]
> > ocaml -install
> I: Installing findlib library 'xmlm'
> I: Running command '/usr/local/bin/ocamlfind install xmlm src/META 
> _build/src/Xmlm.cmx _build/src/Xmlm.cmi _build/src/xmlm.a 
> _build/src/xmlm.cmxa _build/src/xmlm.cma src/Xmlm.mli'
> Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.mli
> Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cma
> Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cmxa
> Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.a
> Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmi
> Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmx
> Installed /usr/local/lib/ocaml/site-lib/xmlm/META

A js_of_ocaml equivalent for the JVM?


Johan Grande asked and Xavier Clerc replied:
>> I used js_of_ocaml several times and was really stunned of how clever
>> (notably because writing interfaces boils down to writing types) and
>> efficient this approach is. Would a similar thing work for the JVM, that
>> is a compiler from ocaml bytecode to java bytecode?

It is not easy to envision such a tool on the JVM, because of the current
restrictions imposed on Java bytecode. As an example, the size of a method
is currently limited to 64Ko, which is clearly way too small for non trivial

>> I guess it wouldn't
>> provide a full interoperability with java, in the sense that creating or
>> extending classes may not be possible (well, why not after all?).
>> However, being able to run an ocaml program on the JVM reusing existing
>> java libraries would be so useful already!

I am currently working on this for OCaml-Java (see below).

>> Are there known obstacles to this? Has anyone tried something in this
>> direction?

Well, no real obstacle as OCaml-Java showed.
However, OCaml-Java 1.x is still a bare proof of concept due to both
poor design choices and JVM limitations. But then came Java 1.7 and
some limitations were removed (e. g. a garbage collector better suited
to functional languages, and an implementation of method handles).
OCaml-Java has been largely rewritten and now exhibit acceptable

>> Would there be a chance to support multicore programming that
>> way?

Yes, it is actually working. But not released yet.
Starting from vanilla OCaml, you "only" need two things:
  1/ have a reentrant runtime;
  2/ have a parallel garbage collector.
OCaml-Java implements the former, while all modern JVMs provide the latter.
So, basically, it just works. The great difficulty is then to provide the good
abstractions to make the life of the programmer as easy as possible.
I mean: who would like to program with locks?

>> I hope these are not silly questions (sorry if they are!)

Thanks for the plug. However, OCaml-Java is quite different and provides two 
  - an equivalent of ocamlrun written in Java (meaning you can interpret
    OCaml bytecode inside a JVM);
  - an equivalent of ocamlc/ocamlopt for Java (meaning you can compile
    OCaml sources to Java jar files to be executed by a JVM).

Stog: static web site and blog generator


Maxence Guesdon announced:
Stog is a kind of Jekyll in OCaml: It is a static web site generator, able
to handle blog posts as well as regular pages.

It is based on a XML engine allowing to apply substitutions on some tags.
Some substitutions are pre-defined, and others can be added by plugins.

Home page:

Code on github:

News about stog:

Hope you'll find it useful.

TypeRex 1.0.0


Thomas Gazagnaire announced:
We are very pleased to announce the first major release of TypeRex, a 
development environment with refactoring capabilities for OCaml.
TypeRex is an open-source software licensed under the GPL and developed by 
OCamlPro and INRIA.

Summary of TypeRex features

* Browsing of identifiers: show type and comment, go to definition,
    cycle between alternate definitions, and semantic grep;
* Strictly semantic-preserving, local and whole-program refactoring:
    o renaming identifiers and compilation units
    o open elimination and reference simplification
* Auto-completion of identifiers (experimental)
* Improved syntax coloring
* Robust /w.r.t./ not-recompiled, possibly unsaved buffers
* Scalable (used regularly on a few hundreds of source files)

How to get it

The easy way is to go to the web page, which should be self-explanatory:

Sources are available on github:

Changes from 1.0.0rc2

The main changes from 1.0.0rc2 are:

* Renaming of faces, which requires prior color customization to be renamed 
* Binary compatibility with OCaml 3.11.2
* Flymake support (contributed by Wojciech Meyer)

The full list of changes is available here:

ocamldoc: Howto crossreference another library?


Maxence Guesdon and Hendrik Tews had the following conversation:
Maxence Guesdon said
> Hendrik Tews said
> >     (** Uses {!print_endline} *)
> >     let f () = print_endline "Hello"
> > 
> > What do I have to do such that ocamldoc generates a
> > crossreference to 
> > file:///usr/share/doc/ocaml-doc/ocaml.html/libref/Pervasives.html#VALprint_endline
> > ?
> OCamldoc can only create links to elements it knows about, i.e. in modules
> given on command line (or loaded from a dump).
> So the answer is: you can't.

After some discussion in the bug tracker, it turns out that one
can get pretty far with a ocamldoc custom generator that uses the
undocumented feature of custom text elements.

See for my preliminary
version of such a generator.

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


Releasing libaio-ocaml-1.0:

New release: Opa 0.9.1:

Ocsigen Server 2.0.4 released:

Ocsigen TyXML 2.0.2 released:

Unison git mirror:

Eff 3.0:

Programming with Algebraic Effects and Handlers:

Preparing release:

OCaml : improved CouchDB access.:

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