OCaml on CLR/JVM? (RE: OCaml <--> ODBC/SQL Server)

OCaml on CLR/JVM? (RE: OCaml <--> ODBC/SQL Server)

[Don Syme]

Now I have to say the obvious: wouldn't it be wonderful if Caml interfaced
with either Java or the .NET Common Language Runtime seemlessly so we
wouldn't have to keep facing these kinds of questions and problems, and
could just leverage existing libraries?   

I'm very interested to know if there are people with some time to spare who
would be keen to work with me toward a .NET version of OCaml.  I've talked
this over from time to time with Xavier, and have done a lot of foundational
work for the core language when building a .NET compiler for Haskell.  If
you think would be interested, or would simply like to join a mailing list
devoted to talking about getting Caml running and interoperating on .NET,
then please let me know!

Cheers,
Don Syme


------------------------------------------------------------------------
At the lab:                                     
Microsoft Research Cambridge                  
St George House                             
Cambridge, CB2 3NH, UK
Ph: +44 (0) 1223 744797                        
http://research.microsoft.com/users/dsyme
email: dsyme@microsoft.com
------------------------------------------------------------------------




-----Original Message-----
From: Vincent Leleu [mailto:me@vleleu.com]
Sent: 05 February 2001 08:52
To: caml-list@inria.fr
Subject: OCaml <--> ODBC/SQL Server


*** Version Francaise a la fin ***

Hello,

I'd like to use OCaml as a CGI scripting language that process forms AND
especially query a SQL Server DB (7.0 or 2000).
I came across a library to easily manage the CGI forms & query strings in
OCaml. This is no probs.

What I cannot find around is a way to easily interrogate and interface in
OCaml with an ODBC data source OR a direct way to send/receive queries
from/to the DB.

If anyone has any idea or even a little clue on where to go, any comment is
welcome.

Thanks a lot

*******

Bonjour,

J'aimerais utiliser OCaml comme language acteur de script CGI qui traiterait
les 'forms' ET surtout interrogerait une base de donnee SQL Server 7.0 ou
2000.
J'ai pu trouver une bibliotheque afin de gerer facilement les forms CGI et
ligne de parametres URL. Pas de probleme avec ca.

Ce que je ne trouve pas est une solution pour facilement interroger et
communiquer d'OCaml avec une source de donnees ODBC OU directement une facon
d'envoyer/recevoir les requetes/donnees vers/de la base de donnees.

Si vous avez la plus petite idee ou piste a me communiquer, tout commentaire
sera le bien venu.

Merci enormement


Vincent Leleu
---
AB Productions
105-A Devonshire Sq.
Jackson, TN 38305
US
---

Re: OCaml on CLR/JVM?

[Xavier Leroy]

> Now I have to say the obvious: wouldn't it be wonderful if Caml interfaced
> with either Java or the .NET Common Language Runtime seemlessly so we
> wouldn't have to keep facing these kinds of questions and problems, and
> could just leverage existing libraries?   

I've been working on and off (mostly off, lately) on an OCaml/Java
interface that works by coupling the two systems at the C level via
their foreign-function interfaces (Java's JNI and OCaml's C
interface).  This was strongly inspired by the work of Erik Meijer et
al on a similar Haskell/Java interface.  (These Haskell guys sure are
at the bleeding edge of language interoperability.  This is the second
interop idea I steal from them, after the IDL/COM binding.)

The low-level coupling is surprisingly easy, including making the two
garbage collectors cooperate: both the JNI and OCaml's C interface
provide enough functionality to get the couping to work without *any*
modification on either of the implementations.  How nice!
The only limitation is that a cross-heap cycle (a Java object pointing
to a Caml block pointing back to the Java object) can never be
reclaimed... (Thanks to Martin Odersky for pointing this out.)

(Actually, the main problem is working around the bugs in Sun's JDK
1.2.2 for Linux.  These guys must be kidding.  Does anyone has a
recommendation for a solid, complete Java implementation (including
Java 2 and of course the JNI) for Linux?)

Of course, the low-level interface is type-unsafe, so the real fun is
to build a type-safe view of Java classes and objects as Caml classes
and objects, and conversely.  I'm still struggling with some of the
issues involved.  For instance, it turns out to be much simpler (for
the implementation, not for the final user!) to map Java objects to
values of abstract Caml types, and treat methods as functions over
these abstract types, than mapping Java objects to Caml objects.  That
was quite unexpected!

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.  This is obvious
in retrospect, but I think many (myself included) often overlook this
point and believe that compiling to the same virtual machine is
necessary and sufficient for interoperability.  It is actually neither
necessary nor sufficient...

While this work started with the JVM, I'm pretty sure it can be made
to work with the .NET CLR, as soon as it will have a foreign-function
interface with features comparable to those of the JNI.  (And I'm sure
this will happen eventually, not only because it makes sense, but also
because Java has it, so .NET must too :-)

Stay tuned for further developments.

- Xavier Leroy

Re: OCaml on CLR/JVM?

[David Mentre]

Xavier Leroy <Xavier.Leroy@inria.fr> writes:

[ about Caml and Java GC cooperation ]
> The only limitation is that a cross-heap cycle (a Java object pointing
> to a Caml block pointing back to the Java object) can never be
> reclaimed... (Thanks to Martin Odersky for pointing this out.)

Regarding GC cooperation, some work has been done on the MALI memory
system [Bekkers86-0:confs]. As Olivier Ridoux explained to me and as far
as I remember, they consider 4 kinds of pointer, some of them to let
garbage reclamation be done latter by the other GC. However, I don't
know if their scheme would solve your inter-GC cycle reclamation. Maybe
you should ask Olivier.Ridoux@irisa.fr directly.

I would be interested to know the solution you applied to this issue. 

>  it turns out to be much simpler (for the implementation, not for the
> final user!) to map Java objects to values of abstract Caml types, and
> treat methods as functions over these abstract types, than mapping
> Java objects to Caml objects.  That was quite unexpected!

Of pure curiosity, why is it so difficult to map Java to Caml objects?
Is it the way control flow evolves between object methods that is
different? Is the typing of OCaml constraining too much the kind of
programs that can be written compared to Java?


Best regards,
d.


@InProceedings{Bekkers86-0:confs,
  author =       "Y. Bekkers and B. Canet and O. Ridoux and L. Ungaro",
  title =        "{MALI}: {A} Memory with a Real-time Garbage Collector
                 for Implementing Logic Programming Languages",
  booktitle =    "Proceedings of the International Symposium on Logic
                 Programming",
  organization = "IEEE Computer Society,",
  year =         "1986",
  month =        sep,
  publisher =    "The Computer Society Press",
  pages =        "258--265",
  ISBN =         "0-8186-0728-9",
}

There is also a "Publication interne" #611, IRISA, 1991, by Olivier
Ridoux : ftp://ftp.irisa.fr/local/lande/or-tr-irisa611-91.ps.Z

-- 
 David.Mentre@inria.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

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

[Xavier Leroy]

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