From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA05192 for caml-red; Fri, 9 Feb 2001 17:04:53 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA19928 for ; Fri, 9 Feb 2001 16:44:51 +0100 (MET) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f19FioL28632; Fri, 9 Feb 2001 16:44:50 +0100 (MET) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_004f_3a84_10eb_2c2a; Fri, 09 Feb 2001 15:46:51 +0000 Received: from somewhere by smtpxd Message-ID: <3145774E67D8D111BE6E00C0DF418B663ED7AF@nt.kal.com> From: Dave Berry To: Xavier Leroy , caml-list@inria.fr Subject: RE: OCaml on CLR/JVM? Date: Fri, 9 Feb 2001 15:49:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr > 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).