Previous week Up Next week


Here is the latest Caml Weekly News, for the week of February 09 to 16, 2010.

  1. The need to specify 'rec' in a recursive function defintion
  2. OCamlSpotter 1.1rc2 for OCaml 3.11.2
  3. Ocaml, Objective-c, and XCode
  4. Win32 OCaml cross-compiler for Debian
  5. OCaml-R binding for the R language
  6. OCaml Meeting 2010 in Paris, 2nd call
  7. Proview PDF Editor for Mac OS X - written (mostly) in OCaml
  8. Other Caml News

The need to specify 'rec' in a recursive function defintion


Deep in this thread, Guillaume Yziquel asked and Alain Frisch replied:
> Is it possible to have polymorphic recursion with vanilla 'let rec'
> invocations?

This is something that Jacques recently merged in the current development
branch. The code below should work with OCaml 3.12.

let length v =
 let rec f : 'a. int -> 'a vec -> int = fun n l -> match l with
    Nil -> n
  | Zero ps -> f (2 * n) ps
  | One (_, ps) -> f (1 + 2 * n) ps
 f 0 v

OCamlSpotter 1.1rc2 for OCaml 3.11.2


Jun Furuse announced:
I have updated OCamlSpotter, a compiler enhancement for source code browsing,
to version 1.1rc2, which is aimed for OCaml 3.11.2 and some enhancements
since its first release.

OCamlSpotter is a tool which finds definition places of various names
(identifiers, type names, modules, etc) in OCaml programs automatically for
you. The original OCaml's -annot option provides the same sort of
functionality but OCamlSpotter provides much more powerful browsing: it can
find definitions hidden in the deep nested module aliases and functor

 - The -annot option of ocamlc and ocamlopt is extended and creates
   <module>.spot files (<module>.spit for .mli), which record the location
   information of the names defined and used in the module.

 - A small application ocamlspot provides automatic where-about spotting of
   the definition of the name you are interested in, using <module>.spot files
   created by the patched compilers.

 - ocamlspot.el provides interactive ocaml-spotting of definition locations in

 - Interfaces for other editors such as vi could be built easily, if you want.

This release of OCamlSpotter is quite near to 1.1, but still in a RC state.
It will become the real 1.1 after 1 or 2 weeks with minimum bug fixes.

Further information and download is available at:

Ocaml, Objective-c, and XCode


Andrew Webb asked and Jeff Scofield replied:
> I have a few questions relating to using Ocaml with objective-c for
> anyone who programs on a Mac.

We've been working with OCaml/ObjC/Cocoa on the iPhone for a while.  We
also have a small subset working on the Mac and have built Mac apps with

> I am aware that there aren't any real bindings between ocaml and
> objective-c/cocoa, so I am investigating rolling my own.

This is what we did.  There was some work on an OCaml/Cocoa bridge, but
it doesn't appear to be finished, and doesn't look like an active
project.  The home page is here:

> 1) Does anyone have experience in interfacing ocaml and objc? Is it
> difficult?

The things that make it easier than it could be are:

(a) There is good documentation on interfacing OCaml and C, and ObjC is
   a clean superset of C.  So the language tools all work together
   quite well.

(b) The OO subsystem of OCaml is a pretty good match for the Cocoa
   design.  With some work, you can use OCaml objects to represent
   Cocoa objects, and vice versa.

The hard parts are:

(a) Cocoa is a very large system, too large for a small number of people
   to build an interface by hand.  A mechanical interface generator
   would be best, but is also a big project.

(b) There's a mismatch between the ObjC reference counting and OCaml GC.

For our work, we just add bits to our interface as we need them.  Memory
management issues are tricky but only need to be solved once in the
lowest layer.  We don't have any experience with the ObjC GC; this might
make things a little trickier.

One thing to note is that we like OCaml because it's very flexible and
expressive.  If you mechanically translate all Cocoa objects and structs
into their obvious OCaml corollaries, you lose a lot of the advantage of
using OCaml.  For example, we map Cocoa NSPoint values into OCaml
2-tuples, not into OCaml records.  And we often use OCaml lists (with
the correct base type) to represent NSArray objects.  Because of this,
we don't think a direct mechanical translation of Cocoa into OCaml is
going to work.  But a mechanical translation with sufficient overrides
probably would.

> 2) Does anyone have a small example project that does mix these two
> languages? I have looked at unison, but it is too big for me to get my
> head around. I am thinking more on the scale of the ubiquitous
> Currency Converter...

I don't know of anything.

> 3) Does anyone who is mixing these languages use Xcode to do so? If
> so, what steps do you need to go through to set that up?

To be honest, we don't currently use Xcode in any non-trivial way.  We
just use its built-in knowledge about packaging up applications.  There
was a project to integrate OCaml into Xcode, but again it doesn't look
like an active project.  The home page is here:
John Whitington also replied:
I've just released a product written in this way:

I just have a normal makefile which builds a .a library from the ocaml code
and its C wrapper as per the instructions in the ocaml manual.

The xcode project then uses the .a and the .h of the wrapper and a few extra
compilation and linking flags. Doubtless with a little bit more effort, Xcode
could be made to call the ocaml makefile.

Here's the OCaml makefile:

       ocamlc cpdf.mli;
       ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa;
       ocamlc cpdflib.mli;
       ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx;
       ocamlc cpdflibc.mli;
       ocamlopt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx cpdflib.cmx;
       ocamlc cpdflibwrapper.c;
       ocamlopt -output-obj -o cpdflibc.o unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx cpdflib.cmx cpdflibc.cmx;
       cp /usr/local/lib/ocaml/libasmrun.a cpdflib.a;
       ar r cpdflib.a cpdflibc.o cpdflibwrapper.o

test:   zlibstubs.o cpdflib.a
       cc -m32 -c cpdflibc-test.c -o cpdflibc-test.o; \
       cc -m32 -L'/usr/local/lib/ocaml' -lunix -lbigarray -lstr -lz -o test cpdflibc-test.o zlibstubs.o cpdflib.a

(The 'test' target shows you the kind of compiler and linker flags you'd need
to put into XCode).

Basically, once you've got the usual ocaml/c interface done, the Xcode part is
no problem.

Win32 OCaml cross-compiler for Debian


Romain Beauxis announced:
Thanks to the great work from Richard Jones on building a OCaml cross-compiler
for windows, we now have a similar package in Debian !

The package is called mingw32-ocaml and has just been accepted yesterday.

OCaml-R binding for the R language


Guillaume Yziquel announced:
This post is to announce the 0.2 release of OCaml-R.

OCaml-R is a binding embedding the R interpreter into Objective Caml code.

Home page:
Download page:
Deb packages:
OCamlDoc API:

The goal of OCaml-R is to provide adequate integration of the R interpreter
into Objective Caml, and a framework suitable to bind R library into OCaml

Version 0.2 is a near-complete rewrite of the 0.1 version by Maxence Guesdon,
with an incompatible API. Main features are:

- Safe handling of R default environment variables at compile time, following
  what is done in littler.
- R Signal handlers do not conflict with OCaml code.
- Integration with findlib, enabling the #require "R.interpreter" to
  initialise statically the R interpreter. Compiling with 'ocamlfind ocamlopt
  -package R.interpreter' also initialises the R interpreter at compile-time,
  so to speak.
- Some (most?) functionalities of the R standalone library are wrapped.
- Low-level binding, in the sense that you construct low-level R calls to
  execute them. You can also parse R code to execute it, if you wish.
- R exceptions are chained back to Objective Caml.
- R's garbage collector is chained with OCaml's garbage collector. This is
  done rather inefficiently for the moment (freeing n R values in O(n^2) time
  complexity), and we expect to bring this down to O(n) with a thin garbage
  collecting layer in the future.
- We provide a double typing scheme, with some subtyping features. A first
  typing mimics the dynamic typing of the R language, while a second typing,
  for the end-user, aims at providing a static typing of R values and
  functions. (This can be bettered).
- S3 classes are supported (static typing is however still unsatisfying). S4
  classes are not yet supported. Help welcome.
- Some basic R datatypes, such as dataframes, are wrapped, and a framework to
  wrap the standard library has been put in place.
- Basic data structures can be converted back and forth between OCaml and the
  R interpreter.
- Ability to inspect (read-only) the inner structure of R values, which is
  quite convenient: you get to know rather quickly what a given piece of R
  code returns, which you need to know to type R code statically in order to
  bind it to OCaml.
- Not thread-safe at all. At least, not more than R is... Lwt-style
  multithreading of R code could be possible, modulo some simple and deep
  (i.e. below R API) changes in the R evaluation functions. POSIX threading a
  single R thread with multiple OCaml threads is not yet possible, but is
  within reach.
- Doesn't interact well the R "Defaults" package.

While most of the code sticks or could stick to the R API, or at least to the
public part of the R headers, there are some functionalities which are
outright out of the scope of the R API. Some of these functionalities are for
convenience only (i.e. inspecting internals of R values), while others are
crucial to the binding (chaining R exceptions to OCaml).

Hopefully, this lays down a foundation on which one could import R
functionalities, libraries and packages to OCaml.

OCaml Meeting 2010 in Paris, 2nd call


Sylvain Le Gall announced:
This is a copy and paste version of:

For the third time, I am proud to invite all OCaml enthusiasts to join
us at OCaml Meeting 2010 in Paris.

This year event takes place in Paris on Friday 16th April 2010.
Subscription is opened and will be closed on Friday 2nd April 2010.

Presentations include:

* Enforcing Type-Safe Linking using Inter-Package Relationships for
* OCaml Debian packages
* The Ocamlviz visualization toolkit
* Cluster computing in Ocaml
* Ocaml in a web startup
* React, functional reactive programming for OCaml
* OASIS, a Cabal like system for OCaml
* OPA, same web, but with types and lambda

As last year, participants are invited to give a talk on what they are
doing with OCaml. You can submit a description of your talk on the wiki
or contact me.

The meeting is sponsored by INRIA, the Caml Consortium and OCamlCore.
Inscription is free but the number of participants is limited.

Further information and inscriptions:

The day after OCaml Meeting, Mehdi Dogguy from PPS helps me to organize
an informal day where OCaml teams can meet to work. We will have 2
classrooms, each can host 45 persons. There will be an internet access
and a blackboard in each room. Inscription is free.

Further information and inscriptions:

Volunteers willing to help before/during these events can contact me
directly. We are particularly looking for a video team. You can also
forward this invitation to any groups that can be interested in (Haskell
user group, CUFP mailing list...)

For people who need further information, you can contact me (see for contact details).

Proview PDF Editor for Mac OS X - written (mostly) in OCaml


John Whitington announced:
Get the demo here:

The back-end is all code shared with the open-source CamlPDF and our other
commercial products. We wrote a C interface, and then compiled it up with
objective C for the interface.

There will be a new release of CamlPDF in a few weeks, with some new
functionality and a new introductory manual, making it easier for people to
get into its somewhat complicated API.

Thanks to the list for your continuing answers to my questions.

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

A Staggering Sequence:

OCaml Meeting 2010 second call:

Heap Up (the Bernstein Sums):

OCaml-R 0.2:

OCaml cross compiler for win32 in Debian !:

PDF Editor for Mac OS X:

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