Previous week Up Next week


Here is the latest Caml Weekly News, for the week of December 07 to 14, 2010.

  1. Define parser and printer consistently
  2. Lwt 2.2.0 released
  3. Js_of_ocaml version 1.0
  4. OBus 1.1
  5. Other Caml News

Define parser and printer consistently


Dawid Toton asked:
I'm going to define a parser and a printer for a simple grammar. 
Is there a way to define both of them in a single construct using some 
existing OCaml tool? 

For example, I have a keyword "function". The usual parser would contain 
a mapping like: 
"function" -> `Function 
and the straightforward printer would do: 
`Function -> "function" 

What is the best way to combine these definitions, so that duplication 
would be minimized? 
To be precise, avoiding duplication is not exactly what I need. I'm 
looking for something that would prevent making inconsistent changes to 
the parser and the printer. 
Ashish Agarwal suggested:
Maybe you will find Pickler Combinators useful:
Pascal Cuoq also suggested:
Take a look at Boomerang:

From the overview:

Boomerang is a programming language for writing lenses—well-behaved
bidirectional transformations—that operate on ad-hoc, textual data formats.
Every lens program, when read from left to right, describes a function that
maps an input to an output; when read from right to left, the very same
program describes a "backwards" function that maps a modified output, together
with the original input, back to a modified input.

Lenses have been used to solve problems across a wide range of areas in
computing including: [...] in parsers and pretty printers
Romain Bardou also suggested:
I'm writing a tool called Parsini which, maybe, does what you're looking 
for. Parsini stands either for "parsing is not interesting" (i.e.: let's 
have a tool which does it quickly for us and move on to interesting 
things such as code generation) or for "parser houdini" or something :p

 From a simple grammar, the tool :
- infers and produces an AST ;
- produces an ocamlyacc source ;
- produces an ocamllex source (optional - you can use your own lexer) ;
- produces a main file with :
   * functions to read your main entries easily from a channel, a file, 
a string...
   * functions to pretty-print your AST.
Your AST is pretty-printed with the Ocaml syntax, not the syntax of your 
own language, which I do not know how to do.

I have not released the tool yet, so nothing is official nor documented 
but you might want to take a look. License will be BSD. I've copied the 
darcs repository on my website :

So you should be able to download it easily with :

darcs get
Yitzhak Mandelbaum also suggested:
PADS/ML can do that for you, and more. You can find information about the PADS
languages and tools here:

including papers and a manual. The website doesn't have the most recent
release of PADS/ML -- i plan to put it up on Github shortly -- but if you're
interested, i'm happy to send you a tarball.

The basic idea is that you specify your grammar as a type-like declaration.
Then, pads/ml generates an AST, parser, printer and some more stuff for you.
The generated parser is like a PEG parser, but with support context-sensitive
parsing. That is, it is deterministic, with ordered choice; and, it is
scannerless. So, the grammars-writing style has some significant differences
from ocamllex and ocamlyacc.

PADS/ML has an Eclipse license.

Lwt 2.2.0 released


Jérémie Dimino announced:
The Lwt team is pleased to announce the release of Lwt 2.2.0. You can
download it at:

Here is a list of changes from the previous version (2.1.1):

 * Bugfixes:
   ** Fix a bug with cancellable threads causing {{{Canceled}}}
      exceptions to be raised randomly
   ** Fix a fd-leak in Lwt_io.open_connection
 * {{{Lwt_unix}}} now use libev instead of select
 * Add thread local storage support to {{{Lwt}}}
 * Add backtrace support to {{{Lwt}}}. Now {{{Lwt}}} exceptions can
   be recored by using the syntax extension with the {{{-lwt-debug}}}
   command line switch.
 * Allow blocking system calls to be executed in parallels
 * Change the type of many functions of {{{Lwt_unix}}}, which now
   return a {{{Lwt}}} thread
 * Add functions {{{Lwt_unix.readable}}} and {{{Lwt_unix.writable}}}
 * Add function {{{Lwt_io.is_busy}}}
 * Add functions {{{Lwt_event.delay}}} and {{{Lwt_signal.delay}}}
 * Add function {{{Lwt_term.render_update}}}
 * Add function {{{Lwt_ssl.embed_socket}}}
 * Add module {{{Lwt_bytes}}} defining operations on bigarrays
   instead of strings
 * Use bigarrays in Lwt_io instead of strings for the internal buffer.
   Lwt_io.make now takes a function that uses a bigarray.
 * Add module {{{Lwt_switch}}}

Js_of_ocaml version 1.0


Jerome Vouillon announced:
I'm happy to announce the first official release of Js_of_ocaml,
a compiler from OCaml bytecode to Javascript.

This tool let you write OCaml programs that run on Web browsers.

Js_of_ocaml is easy to install, and use thereafter, as it works with
an existing installation of OCaml, with no need to recompile any
library.  It comes with bindings for a large part of the browser APIs.

The project page is:


The compiler has been used to implement some noteworthy examples,
such as:
- an interactive 3D view of the Earth
- a graph viewer


According to our benchmarks, with state of the art Javascript engines,
the generated programs runs typically faster than with the OCaml
bytecode interpreter ( ).

Js_of_ocaml performs dead code elimination in order to generate
compact code: the Javascript file produced is usually smaller than
the input bytecode file, and often much smaller.


Project home page
Get source code    darcs get


Js_of_ocaml performs a fairly faithful translation.  The order of
evaluation is preserved.  Modular arithmetic is used for integers (but
with 32 bit integer).  It does not support tail calls (function calls
in tail position), as this would be too expansive.  However tail
recursion (self call in tail position) is properly optimized.

Explicit coercion functions can be used to convert Ocaml values to
Javascript values, and conversely (for instance, to map OCaml mutable
strings to Javascript immutable UTF-16 strings, or to map OCaml
booleans to Javascript booleans).  A Camlp4 syntax extension makes it
possible to invoke Javascript methods in a type safe way.


Ocamljs is a compiler from OCaml source code to Javascript.  Jake
Donham has written a fair comparison of the two tools:

Ocamljs is a back-end to the existing OCaml compiler.  Thus, contrary
to Js_of_ocaml, you need to perform a distinct installation of OCaml
to use Ocamljs, and you have to recompile all the libraries you may

Ocamljs follows a different philosophy: it attempts to merge OCaml
datatypes with the corresponding Javascript datatypes.  For instance,
OCaml objects are implemented as Javascript objects.  Conversely,
Javascript objects are given an OCaml object type.  A mixed
representation of strings is used: mutable OCaml-style strings and
immutable Javascript strings both have the same type.  All this is
good for interoperability, but can be a source of incompatibilities
and can result in runtime errors not caught by the type checker.

Ocamljs optimizes tail recursion, but this comes at a large
performance cost.
Yitzhak Mandelbaum asked and Jerome Vouillon replied:
> Do you mean all tail-calls come a large cost, or only those outside
> of plain tail-recursion?  Either way, could you give us some more
> intuition as to why this happens, and why js_of_ocaml doesn't suffer
> from the same problem (assuming it applies to tail-recursion)?

I meant tail calls, indeed.  Tail recursion (when a function calls
itself recursively in tail position) can be optimized efficiently by
wrapping the function body inside a loop.  This is what Js_of_ocaml

For optimizing tail calls in general, you need to use trampolines.
Instead of calling a function in tail position, you return this
function and its arguments.  Then, a piece of code called a trampoline
takes care of invoking repeately the functions it receives this way
until a final result is returned.  This is expansive.  You have to
make sure that this piece of code is there whenever a function is
invoked in tail position.  Also, the JIT compilers cannot optimize the
trampoline, as the functions it will have to call, and their number of
arguments, are unknown.

OBus 1.1


Jérémie Dimino announced:
I'm happy to announce the release 1.1 of OBus, a pure OCaml
implementation of the D-Bus protocol.

OBus aims to make it easy to use and provide D-Bus services in OCaml. It
can generate interfaces to D-Bus services from introspection files, it
provides integration of D-Bus methods, signals and properties to native
ocaml functions, mapping between D-Bus types and OCaml types, ... But it
is also possible to write low-level D-Bus application using OBus.

OBus is distributed with predefined OCaml interfaces to the following
services: Hal, NetworkManager, Popup notifications, PolicyKit, UDisks
and UPower.


Project page:
Api documentation:

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

Release of Lwt version 2.2.0:

Installing OCaml Batteries:

Lwt 2.2.0:

OBus 1.1:

Release of Js_of_ocaml version 1.0:

FusionForge migration:


optimising texsearch:

CPDFTK: Supported, Faster PDFTK:

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