Previous week Up Next week


Here is the latest Caml Weekly News, for the week of 24 to 31 August, 2004.

  1. Announcement of a business-oriented Objective CAML resource site
  2. ocamllex tutorial (ver 0.2)
  3. Alternative Bytecodes for OCaml
  4. SF Bay Area SIG
  5. C++ Throws
  6. Support for students attending MetaOCaml Tutorial and Workshop (Deadline September 5th, 2004)

Announcement of a business-oriented Objective CAML resource site


Richard Jones announced:
[I'll try to keep this brief and to-the-point.  Hopefully only very
very occasional messages about this to caml-list should be necessary.]

A group of business users of Objective CAML, including Nicolas
Cannasse and myself, are building a website containing resources for
the promotion of the language to business users.  The website is here,
and we would welcome contributions:

In particular, if you are a programmer or consultant who would like to
offer your services to businesses within your area, we would
appreciate you adding a note here:

If you are a company which uses Objective CAML, and you don't mind
other local businesses contacting you, please add a note here:

If you are in / run a user group, then add a note here:

If you'd like to know more about our objectives for OCaml in business,
then you can read about them here:

ocamllex tutorial (ver 0.2)


SooHyoung Oh announced:
- fix some bugs (Thanks Martin)
- add "Keyword Hashtable" section
- add "Nested Comments" section
- add example for lexing ambiguities (chapter 5).
- include some examples in complete form
- information of the source of document
- information of PDF file (A4 size) of the document
- information of the source of examples


This is a tutorial on how to use ocamllex which is distributed with Ocaml

This tutorial borrowed lots of part from flex manual, and some part from
Chap. 12 Lexer and parser generators (ocamllex, ocamlyacc).

The companion tutorial for ocamlyacc will be available in one or two weeks

Please mail all comments and suggestions to <shoh at compiler dot kaist dot
ac dot kr>

This tutorial is work-in-progress. The latest version can be found at .

You can find the source of this document in ocamllex_tutorial_src.tar.gz,
and for printing, pdf (A4 size) is presented.

You can download the source of examples used in this document from

Last updated: 2004-08-25

Alternative Bytecodes for OCaml


John Goerzen asked:
I come to OCaml from a Python background, and one of the most
interesting bits of technology for Python is Jython[1].  Jython is a
pure Java implementation of the Python interpreter and native-code
libraries.  It allows Python programs to run unmodified in a Java
environment.  More powerfully, though, Python programs can use Java
classes as if they were native classes.  No glue code is required for
this; it Just Works.  To a somewhat more limited extent, Python classes
can also be made available to Java classes.  This makes Python an
interesting choice to add more dynamic capabilities to Java code, and
it expands the set of available libraries to Python programs to include
anything available for Java.  I've used these capabilities for several
purposes -- one of the more recent is the zxJDBC module, which exposes
a Python DB-API interface to any database that has a JDBC

One of my continuing complains about OCaml is the breadth of libraries
available for it.  It is getting better thanks to the hard work of
many, but IMHO, still lags behind Python, Perl, and Java.

So one of the things I've been thinking about lately is integrating
OCaml with either Java or the .NET CLI in a manner similar to Jython.
I've done some googling on the topic and it seems nobody is working on
this yet.  I just wanted to check and see if that's true.

I see several possibilities with both of those paths:

 * An ocamlc/ocamlrun that execute under Java or .NET and compile/run
normal OCaml bytecode

 * An ocamlopt-equivolent that would compile OCaml code directly to Java
or .NET bytecode

I have found a language called Nemerle[2] that seems to be very similar
to OCaml, though with a different syntax.


Richard Jones said:
>  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run
> normal OCaml bytecode

This interesting project was posted on the Wiki yesterday.  It
generates code which runs on the .NET CLR.  I'm not exactly sure how,
whether it's a modified compiler, or a translator of OCaml bytecode:

What will be interesting will be to see how well it allows one to call
.NET libraries, and how well it works on Mono.
Lars Nilsson added and John Goerzen said:
> I guess one can always mention F# in this context.

Also, it appears there is a SML version for .NET:
Raphael Montelatici described OcamIL:
Here are some explanations on OcamIL.
OcamIL compiles Ocaml programs to verifiable MSIL bytecode.
I  have not advertised at all about it so far because I still consider it is
not mature yet.

Some implementation details:
OcamIL is a modified ocamlopt compiler. Modifications are made as late as
possible in order to achieve maximum compatibility with ocamlc/opt. One big
issue is the compilation of an untyped intermediate language to a typed

Two tracks have been followed : 1) type reconstruction and 2) type
1) The current OcamIL distribution relies on the first approach. It gives
enough good results to allow to bootstrap OCamIL and build an Ocaml
toplevel for .NET. Interoperability with C# has been successfully tested.
2) However, it leads to unadequate data representations that entail poor
performance. I'm currently working on the second approach.
This involves a lot of code restructuration. Source files (as a patch to
ocaml sources) together with a correct license will appear in the next
release (expected late october ?)

About interoperability:
We do not want to add weird FFI features to the Ocaml syntax. We prefer an
IDL approach, inspired by what have been done for Caml and Java by the
OJacare project ( ).

About mono:
OcamIL is developped and tested on windows, but I'm willing to make it
compatible with Mono.
However, mono still lacks .NET compatibility. OcamIL relies on parts of the
Reflection library that are not available yet.
Moreover, the mono bytecode interpreters behaves strangely: some executables
produced by OcamIL don't run in the bytecode interpreter, but do run when
previously compiled by the mono bytecode-to-nativecode compiler.
Please Mono users wait for the next OcamIL release, which will be announced
on this list.
Nicolas Cannasse suggested:
> I see several possibilities with both of those paths:
>  * An ocamlc/ocamlrun that execute under Java or .NET and compile/run
> normal OCaml bytecode
>  * An ocamlopt-equivolent that would compile OCaml code directly to Java
> or .NET bytecode

I started some weeks ago a library to enable the OCaml programmer to
manipulate Java bytecode, so it can :
- generate valid .class files
- read .class files and interpret them in OCaml

The library already have a full .class parser but still need the
corresponding printer and a small OCaml JVM in order to be able to interpret
java bytecode. That might be added easily, people interested in helping or
getting informations can contact me directly.

SF Bay Area SIG


Shishir Ramam said:
I am interested in starting a SF Bay Area Ocaml SIG to meet
on a regular basis. The general idea being to talk all things Ocaml.

Would like to poll these forums to see if others are interested
(with apologies if you get multiple copies of this email).

Please get in touch offline if this is of interest to you.
He later added:
Since there is some interest, I have started a yahoo group to manage
the forum -

The link has also been updated at the Ocaml Alliance Network Wiki.
My email was already on there. Apparently, Ocaml is not alone in being quick! :)

Please feel free to sign up. Postings are restricted to members only, in
an attempt to limit spam. Let's see how that works out.

From now on, all related communications will be on the group mailing list.
Thanks for tolerating the noise if this was not of interest to you.

C++ Throws


In the middle of a thread about C++ throws, Xavier Leroy said:
> I do find it amazing that C++ would be dumb enough to try to scaffold raw
> stack frames, instead of using some kind of dynamic link pointers to reach
> each frame.

There are indeed two "schools" of exception handling: one that unwind
stack frames one by one until an exception handler is found, and one
that maintains at run-time a chaining between exception handling
blocks on the stack, so that no stack searching is necessary when an
exception is thrown.

The first school is exemplified by C++, Modula-3, Java and C#; the
second school by Lisp, Caml and to some extent Prolog (if you view
backtracking as a generalization of exception handling).

A good description of the two approaches is the following paper:

  "A Single Intermediate Language That Supports Multiple Implementations
   of Exceptions",, Norman Ramsey and Simon Peyton Jones, PLDI 2000.

The two approaches have very different performance trade-offs.  To
make things worse, many people from the first school are not even
aware of the second approach.  So, as usual, there is no hope to see
the world converge on a single exception mechanism.

>  How in the world would any kind of cross-language
> interoperability ever function if this were the case.

Cross--language exception interoperability is certainly a challenge.
There are C compilers (MSVC, Tru64 cc) that provide C++-style
exception handling compatible with C++, but that's not too hard given
that the same compilers double as C++ compilers :-)  Some ABI
(Application Binary Interfaces) specify the format of stack
descriptors and the unwinding algorithm, but not all.

The only portable way is to install catch-all exception handlers at
the boundaries between the two languages whose job is to convert
exceptions from one language into exceptions from the other language.
The Caml bytecode interpreter does something like this when
interoperating with C, using setjmp/longjmp to represent exceptions on
the C side.

For C++ to Caml callbacks, you can use callback_exn to invoke the Caml
code; it reifies whatever Caml exceptions can get out of the Caml code
as special return values, which the C++ wrapper can test and then
throw the appropriate C++ exception.

For the reverse direction (Caml calling C++), I'm afraid the only
solution is to use a C++ catch-all clause to turn C++ exceptions into
Caml exceptions.

Hope this clarifies the issue.

Support for students attending MetaOCaml Tutorial and Workshop (Deadline September 5th, 2004)


Cristiano Calcagno said:
The National Science Foundation (NSF) has kindly provided a
number of stipends to support students travel and participation
to attend the MetaOCaml Tutorial and/or the MetaOCaml Workshop:

Awards will be made on the basis of relevance to the students
education and research activities.  To apply, please send an
email to by September 5th.  The email should include:

    1) Primary interest (Tutorial or Workshop)
    2) Explanation of relevance to your current educational
       and/or research goals (200-500 words)
    3) Secondary interest
    4) Explanation of relevance
    5) Estimated travel expense

Reimbursements will be made based on submitted expense receipts.
Students submitting papers to the MetaOCaml Workshop are eligible
for stipends.  Amount of stipend will be indicated when you are
notified of the result of your application.

Applications should be sent to by September 5th, 2004.

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'&lt;1':1

If you know of a better way, please let me know.

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