[Caml-list] Re: OCaml on CLR/JVM?

[Xavier Leroy <Xavier.Leroy@inria.fr>]

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