Previous week Up Next week


Here is the latest Caml Weekly News, for the week of July 31 to August 07, 2012.

  1. Enhanced OCaml Documentation 4.00
  2. OCaml-Java 2.0 preview: call for testers
  3. type inference with classes
  4. Yypkg 1.5.0
  5. Argot: 1.1 release
  6. Two questions about lex/yacc and lablgtk/gl
  7. Mingw-builds 1.0 rc1
  8. Other Caml News

Enhanced OCaml Documentation 4.00


Hendrik Tews announced:
I would like to announce

The Enhanced OCaml Documentation 
Version 4.00
available via

This version of the OCaml manual enhances the original html
version in the following way:

- Changes (wrt version 3.12) are tagged with icons and color 

- an additional appendix contains all grammar rules

OCaml-Java 2.0 preview: call for testers


Xavier Clerc announced:
The OCaml-Java is a project whose goal is to allow compilation
of OCaml sources to Java bytecode, thus allowing execution on
any JVM. The objectives are to gain access to a greater number
of libraries, and to be able to take advantage of multiple cores.

Quite a lot of work has been done in order to greatly improve
the performances of the code generated by the "ocamljava"
compiler. Roughly speaking, some preliminary benchmarks
seem to indicate that ocamljava-generated code is most of
the time less than three times slower than ocamlopt-generated one.

This very mail is sent to try to gather feedback from the community.
As of today, the source is neither stabilized nor complete, and only
a binary version is available. Installation is very simple: uncompress
the archive, and put the "bin" subdirectory in your path.
More information can be found in the "README" file of the archive.
The archive can be downloaded at the following address:

For this version, I am mostly interested in compatibility reports,
and performance considerations. Although the compiler is already
able to compile itself, it is probably wise to start with smaller

type inference with classes


Ivan asked and Alain Frisch replied:
> I've mentioned that in some cases ocaml can't infer type (or maybe it
> can, but didn't want to...) of some objects.
> Right to this moment, I've just do as ocaml wants - annotate a type and
> move forward. But now I want to make things more consciously. The reason
> is simple - sometimes ocaml infers types correctly and denotes a type
> error in my code, but I, mistakenly thinking that it can't infer type of
> object, loose my time in useless type annotating of different
> identifiers. Or vice versa, the code is correct, except for some
> undecidable object type, and I spend h^Wminutes in checking my code for
> errors.
> So, I'would like to know the rules of type inference failures with
> object types. In what cases an object type can and must be inferred, and
> in what it must be annotated explicitly?
> Can someone share this arcane knowledge or, at least, point me at some
> sources, explaining this issue?

I don't know if this covers all the case, but you need to keep in mind
the following points. Feel free to add to the list.

1. The type-checker will never infer that a method is polymorphic. You
need to tell it.

method f = (this # g 1, this # g true)
method g x = x


method f = (this # g 1, this # g true)
method g: 'a. 'a -> 'a = fun x -> x

2. Same for labeled and optional arguments on methods, when the type
for the method to be called is not known.

class virtual c =
method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2


class virtual c =
method f = this # g ~x:1 ~y:2 + this # g ~y:1 ~x:2
method virtual g: x:int -> y:int -> int

(Note: this is really not specific to objects, a simple (fun g -> g
~x:1 ~y:2 + g ~y:1 ~x:2) has the same effect, but it's likely to hit
you if you use virtual classes.)

3. When declaring classes, the inferred type must have no free
variable. So while the expression "object method f x = x end" is
allowed and is inferred to have a type "< f : 'a -> 'a >", the
following class declaration is rejected:

class c = object method f x = x end

Depending on what you want to do, you can either force a specific type
or make the class parametric:

class c = object method f x : int = x end
class ['a] c = object method f x : 'a = x end
Ivan then asked and Jacques Garrigue replied:
> Thanks for nice and structured answer! 
> I'll try to expand it with my cases, but due to lack of comprehension they 
> will not be so clear =)
> So the setup is follows: I have a class with a type explicitly specified in 
> mli file. No inference on it's methods. And a function, that takes some 
> object and type system tries to infer what objects it can accept. 
> Starting from a simple case:
> let reset_env_model state v =
> let q = Queue.create () in
> Queue.iter (fun p -> v#expand_row p) q
> produces an error:
> This expression has type GTree.view
> but an expression was expected of type < expand_row : 'a -> unit; .. 
> >
> Types for method expand_row are incompatible
> because expand_row method of type GTree.view has type:
> expand_row : Gtk.tree_path -> unit;

> I think, that compiler have a reason to refuse this code: function wants a 
> method, that can take an arbitrary value of type 'a, but I pass a method 
> that has a covariant type Gtk.tree_path in position left to arrow. So he 
> complains correctly. I agree =) I think that this case has some 
> correspondence with your case #1.

Your assumption is wrong. A function never "requires" polymorphism from an 
It may require a polymorphic method, but only if the type of this argument is 
given explicitly.

The fact is that, at least in lablgtk-2.14.2 (the current version), the type 

expand_row : ?all:bool -> Gtk.tree_path -> unit

So this enters the second category of methods with optional arguments.

> But, why in the following code:
> let reset_env_model state v =
> let q = Queue.create () in
> let m,_,_ = State.env_model state in
> m#foreach (fun p _ -> if v#row_expanded p then Queue.push p q; false);
> set_env_model state v;
> Queue.iter (fun p -> v#expand_row p) q
> compiler cannot infer, that object p has type Gtk.tree_path, and with this 
> proposition imply, that the expand_row method has a type "Gtk.tree_path -> 
> unit"? 

This is exactly the same problem as above.

In some situations it may be a good idea to use the -principal flag, to get 
more regular behavior from the type checker with respect to required type 
Ivan then asked and Jacques Garrigue replied:
>The first thing I've tried was specifying explicitly argument ~all. But
>compiler refused to accept this too, with exactly the same error message...

For the ~all argument to be properly processed, you first need the
type of the method to be known.
The best solution is to put a type annotation on v.
The next solution is to pass an explicit optional argument:

v#expand_row ?all:None x

I don't like it much because parameter order matters.

Yypkg 1.5.0


Adrien Nader announced:
I'm happy to announce the release of Yypkg 1.5.

Yypkg is a small, fast, platform-agnostic package manager. It can be
used to manage any directory. It is built to help cross-compilation
setups and it works both for and on Windows.

Functionality changes:
- doesn't rely on sexplib's camlp4 extension anymore (*)
- handles running shell scripts when installing a package (yypkg)
- skips packaging libtool's .la files (makeypkg)
- doesn't try to adapt hard-coded paths in .pc files to the location
they are installed to: there are too many hard-coded paths anyway
- improve the GUI (still work to do)

- bad code with select() when reading bsdtar's output (yypkg -install)
- don't mix bsdtar warnings with filenames during package installation
(yypkg -install)
- properly extract files in directories which are not ".".

Yypkg is hosted on the OCaml forge at:

It can be download from:

Argot: 1.1 release


Xavier Clerc announced:
This post announces the 1.1 release of the Argot project, whose goal is to provide 
an enhanced HTML generator for ocamldoc, released under the GPL v3.

Home page:
Preview page (for search feature):
Forge page:

Main changes since 1.0:
- full-text search over comments
- search by type can now take advantage of type manifests
- search by type now handles labeled parameters
- search by type now handles optional parameters
- new '-search-frame' command-line switch to have search panel in a frame,
rather than in a window
- update for OCaml 4.00.0
rixed asked and Xavier Clerc replied:
> I can't build it on ocaml 3.12.1:
> File "src/search.mli", line 21, characters 30-54:
> Error: Unbound module Odoc_html.Generator
> According to ocamlobjinfo, Odoc_html module is not present in odoc_info.cma.
> OCaml's ocamldoc/Makefile lists odoc_html in EXECMOFILES but not in CMOFILES,
> which is the list of modules gathered in odoc_info.cma. Aparently it was
> not deemed worth of installation back then. :-)

Well, sorry about that but 3.12 is no longer supported.

The ocamldoc APIs are different in 3.12 and 4.00, and I
don't want to support both.

Two questions about lex/yacc and lablgtk/gl


Nicolas FRANCOIS asked:
I'd like to create a 3D dynamic geometry application. I developped
DrGeoCaml a few years ago, but it's now quite old, and my Caml practice
is a bit rusty. So a few questions to start on the right tracks :

1) I'd like to create a parser, with the help of ocamllex/yacc, but
I don't find the help pages very instructive. Is there a good
tutorial like "Ocamllex for complete numbs" ?

2) I'd like to use lablgtk for the graphic interface, and lablgl for
the 3D visualization. It's mentionned in lablgtk documentation that
this can be done, but once again, i didn't find much help. Any clue ?
Gerd Stolpmann replied to the first question:
I don't know of any such tutorial, but you can also watch out for a
lex tutorial (i.e. for C), because the matching algorithm is exactly
the same. The syntax is of course different, but I guess this is the
easier part, and extractable from the manual (or sample code).

Regarding ocamlyacc, consider to use Menhir instead. It includes a
mode where grammar conflicts are explained by example, and in my
experience this is the difficult part of developing a grammar. And it
has macros, and other convenience features.
Oliver also replied:

Florent Monnier replied to the second question:
We can use LablGTK for OpenGL windowing with any OCaml-OpenGL bindings.
There are currently 3 OCaml-OpenGL bindings:

- LablGL (the older one)
- GLCaml (generated code)
- glMLite ()

As long as I know, if you want to write forward compatible OpenGL code in 
OCaml, you can only do so with glMLite.

If you need some help for LablGTK-OpenGL (any binding) or OpenGL in
OCaml (any binding) just ask.

Mingw-builds 1.0 rc1


Adrien Nader announced:
Following the new version of yypkg, here is a release of mingw-builds, a
whole build environment for windows, with all the benefits of a package
manager, everywhere.

The website is currently at:

The doc to run build scripts yourself is currently a bit hidden since
it's a first release and I can't drown people in details, but be assured
the system is portable and reproducible, easily.

Compared to the previous releases, this:
- changes the build infrastructure to something much better
- requires less work for new packages
- has its own builds of the toolchain
- runs in a chroot (no other sane way)

It still doesn't provide ocaml packages because of the lack of an
upstream cross-compiler. I expect this to be solved relatively soon.

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

Merge Right:

Opa 1.0.5 released: great improvements in Node.js backend:

A Helping Phantom Hand:

Register allocation in CompCert:

OCaml Asterisk:

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