Re: OCaml on CLR/JVM?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> Now I have to say the obvious: wouldn't it be wonderful if Caml interfaced
> with either Java or the .NET Common Language Runtime seemlessly so we
> wouldn't have to keep facing these kinds of questions and problems, and
> could just leverage existing libraries?   

I've been working on and off (mostly off, lately) on an OCaml/Java
interface that works by coupling the two systems at the C level via
their foreign-function interfaces (Java's JNI and OCaml's C
interface).  This was strongly inspired by the work of Erik Meijer et
al on a similar Haskell/Java interface.  (These Haskell guys sure are
at the bleeding edge of language interoperability.  This is the second
interop idea I steal from them, after the IDL/COM binding.)

The low-level coupling is surprisingly easy, including making the two
garbage collectors cooperate: both the JNI and OCaml's C interface
provide enough functionality to get the couping to work without *any*
modification on either of the implementations.  How nice!
The only limitation is that a cross-heap cycle (a Java object pointing
to a Caml block pointing back to the Java object) can never be
reclaimed... (Thanks to Martin Odersky for pointing this out.)

(Actually, the main problem is working around the bugs in Sun's JDK
1.2.2 for Linux.  These guys must be kidding.  Does anyone has a
recommendation for a solid, complete Java implementation (including
Java 2 and of course the JNI) for Linux?)

Of course, the low-level interface is type-unsafe, so the real fun is
to build a type-safe view of Java classes and objects as Caml classes
and objects, and conversely.  I'm still struggling with some of the
issues involved.  For instance, it turns out to be much simpler (for
the implementation, not for the final user!) to map Java objects to
values of abstract Caml types, and treat methods as functions over
these abstract types, than mapping Java objects to Caml objects.  That
was quite unexpected!

One thing I learnt is that the real problem with language
interoperability is not how to compile language X to virtual machine Y
(this can always be done, albeit more or less efficiently), but rather
how to map between X's data structures and objects and those of all
other languages Z1 ... Zn that also compile down to Y.  This is obvious
in retrospect, but I think many (myself included) often overlook this
point and believe that compiling to the same virtual machine is
necessary and sufficient for interoperability.  It is actually neither
necessary nor sufficient...

While this work started with the JVM, I'm pretty sure it can be made
to work with the .NET CLR, as soon as it will have a foreign-function
interface with features comparable to those of the JNI.  (And I'm sure
this will happen eventually, not only because it makes sense, but also
because Java has it, so .NET must too :-)

Stay tuned for further developments.

- Xavier Leroy