From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA27859; Wed, 14 Feb 2001 20:32:08 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA28482 for ; Wed, 14 Feb 2001 20:32:08 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f1EJW4P19002; Wed, 14 Feb 2001 20:32:04 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA28488; Wed, 14 Feb 2001 20:32:04 +0100 (MET) Date: Wed, 14 Feb 2001 20:32:04 +0100 From: Xavier Leroy To: David Mentre Cc: Don Syme , caml-list@inria.fr Subject: [Caml-list] Re: OCaml on CLR/JVM? Message-ID: <20010214203204.B28371@pauillac.inria.fr> References: <0C682B70CE37BC4EADED9D375809768A02DB1D6E@red-msg-04.redmond.corp.microsoft.com> <20010208200330.A10340@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from David.Mentre@inria.fr on Fri, Feb 09, 2001 at 10:06:37AM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > [The MALI memory system.] I would be interested to know the solution > you applied to this issue. Currently, none: the cycle is never deallocated. But thanks for the interesting references. > Of pure curiosity, why is it so difficult to map Java to Caml objects? There are a zillion sources of mismatches; some are easy to solve, some not so. For instance: - Static overloading: Java has it, Caml doesn't. So what do you do when your Java class has several definitions of method m, distinguished only by their argument types? My current solution is to have distinct methods on the Caml side, named m, m', m'', m'3, m'4, etc. (Thanks God, the quote is not valid in Java identifiers!) Of course this sucks because the programmer has to refer to an automatically-generated documentation to find the Caml name of a Java method used at a particular type. - Type equivalence and subtyping policy: Java is by name, Caml is by structure. Actually not a big deal, since abstract data types in Caml can be used in creative ways to simulate Java's by-name behavior. - "null" objects: any Java object reference can be "null"; Caml objects are never "null". One can map Java object references to a Caml "option" type, but this is quite heavy-handed on the Caml client side. My current solution is to map a Java "null" to special Caml objects that raise exceptions whenever one of their methods is called. - Publically-accessible fields: in Java, fields are accessible from the outside of an object; in Caml, only the object's methods can see them. Moreover, the Caml object is distinct from the Java object: it just delegates its methods to the Java object. Solution: map Java fields to get/set methods on the Caml side. In the reverse direction, it's harder: basically, a Caml object can only implement a Java interface (only methods, no fields). - Recursion between classes: in Java, classes can be arbitrarily recursive, even across packages. And they are: for instance, java.lang.Object (the root of the Java class hierarchy) is actually mutually recursive with about 20 classes spanning 4-5 packages! In Caml, only classes defined simultaneously in the same module can refer recursively to each other. This is my current show-stopper. The initial approach was to map a Java package to one Caml module, allowing inter-package recursion, but not cross-package recursion. But that is not enough! One actually needs to do a "connected components" analysis on the Java classes, map each component to a Caml module, then re-assemble the modules per-package in order to give a nice user view... In summary: it's hard. But stay tuned for further news. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr