RE: OCaml on CLR/JVM?

[Don Syme <dsyme@microsoft.com>]

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

Well, I didn't exactly propose a technical solution...  

Of course there's hard work to be done to realise this vision, but in
principle a clean interop story sure beats the endless rehashing of other
people's code in language X as a library in language Y.  Myself and others
involved in the Microsoft Project 7 are working on one approach to achieve
this interop, i.e. compiling languages directly to .NET MS-IL, in the style
of MLj, often adding extensions to the language in order to improve the
interop.  We are also working on improving the .NET infrastructure,
proposing support for features such as parametric polymorphism in MS-IL.  

Xavier is also working on a solution for OCaml, as he mentioned, though the
problem of how to reflect the constructs of an object model into ML, Haskell
or OCaml remains similar whichever approach you take to actually running the
stuff.

> To look at it another way, OCaml already shares a platform with C (at
least
> with the native-code compiler), so all the C libraries are already
> available.
> Yet it can still be a lot of effort to link with a C library.  Why should 
> Java and .NET be any easier?  Also, look at the effort that went into
making
> an ML/Java system with MLj.

There are several reasons why it is easier: exceptions, for example, can be
propogated across the interop boundary, without any effort at all if you
compile to MS-IL of Java bytecode.  If you're compiling to bytecode you can
also ensure more compatibilities of representations, e.g. make sure ML
int64's are exactly representationally equivalent to C's int64s.  Note if
you don't compile to a bytecode then you even have to marshal integers
across the interop boundary in Caml, though this could be automated.

You can also transfer objects more consistently, as the semantics of the
object models of Java and .NET are fairly simple in contrast to C, e.g. no
need to have an IDL to help interpret pointers as "in-out", "in", "out"
parameters.

While at a certain level I like Xavier's approach, i.e. maintaining two
runtimes, garbage collectors etc., I have troubles seeing it scaling to the
multi-language component programming envisioned as part of .NET approach
(and indeed currently in practice with C#, C++, VB.NET and other .NET
langauges).  Two GC's are already trouble enough (performance might suck as
they will both be tuned to fill up the cache), but if you have components
from 10 languages in one process?  10 GCs competing for attention?  Maybe it
can be made to work, but there's a certain conceptual clarity in just
accepting that a GC should form part of the computing infrastructure, and
share that service.  These are the aspects of the .NET approach that I find
quite compelling.

As an aside, I think it would be an interesting question to say "OK, let's
take it for granted that the end purpose of our language is to produce
components whose interface is expressed in terms of the Java or .NET type
systems, but which retains as many of the features and conceptual simplicity
of OCaml and ML as possible."  I'm not sure exactly what you'd end up with,
but whatever it was it could be the language to take over from C# and/or
Java (if that's what you're interested in...)  But without really taking
Java/.NET component building seriously right from the start I feel you're
always just going to end up with a bit of a hack - an interesting, usable
hack perhaps, but not a really _good_ language.

Probably the greatest recurring technical problem that I see in this kind of
work is that of type inference, and the way both the Java and .NET models
rely on both subtyping and overloading to help make APIs palatable.  Type
inference just doesn't work well with either subtyping or oveloading.  This
is a great, great shame, as it's obviously one of the main things ML has to
offer to improve productivity.  

Cheers,
Don

P.S. As for threads - I don't think the story is half as bad as you might
think.  After all, OCaml threads map down to Windows threads at some point,
and I just don't see that there are that many special logical properties of
typical ML and Caml threading libraries that make it semantically ridiculous
to share threads between languages (though it is true asynchronous
exceptions can make things hard when compiling to a bytecode).  But I'll
admit I'm not an expert on this.