Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: OCaml on CLR/JVM?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Dave Berry <dave@k...>
Subject: RE: OCaml on CLR/JVM?
> From: Xavier Leroy [mailto: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 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.  As Xavier
said:

> 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.  

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.

(To be fair, I've never tried linking OCaml to C myself; I'm only judging
the
difficulty by traffic on this mailing list.  It seems to be simpler than
many
other ML compilers, but still with potential pitfalls). 

Threads are another area of potential problems.  In fact they can be a total
minefield.  

Xavier also wrote:
> These Haskell guys sure are
> at the bleeding edge of language interoperability. 

I don't entirely agree with this -- they may be at the leading edge of
publicly
documented implementations, but I know of commercial Lisp and Dylan
implementations
that are notably more sophisticated.  Unfortunately the techniques that
those
implementations use are proprietary, so I guess this doesn't have much
practical
impact for anyone else.

That said, I was pleased (if a little envious) when the Haskell people
successfully
published some papers about foreign-language interfaces.  I had rather
assumed that the
academic community wouldn't be interested in such mundane engineering
issues.
I did notice that some of the papers still used greek letters and
denotational
semantic-style equations to describe a fairly straightforward translation -
perhaps
these softened the blow to the readers?  ;-)  (I hope this doesn't sound
harsh; I 
intend it mainly in jest).