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 WAA16944 for caml-red; Sat, 10 Feb 2001 22:32:14 +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 XAA27877 for ; Fri, 9 Feb 2001 23:20:02 +0100 (MET) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f19MK1L03133 for ; Fri, 9 Feb 2001 23:20:01 +0100 (MET) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Feb 2001 14:07:44 -0800 (Pacific Standard Time) Received: by inet-imc-04.redmond.corp.microsoft.com with Internet Mail Service (5.5.2653.19) id <1TCAC8W1>; Fri, 9 Feb 2001 14:05:23 -0800 Message-ID: <0C682B70CE37BC4EADED9D375809768A48FD31@red-msg-04.redmond.corp.microsoft.com> From: Don Syme To: "'Dave Berry'" , Xavier Leroy , caml-list@inria.fr Subject: RE: OCaml on CLR/JVM? Date: Fri, 9 Feb 2001 14:05:13 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: weis@pauillac.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. 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.