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

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

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

In short, because it is possible to automate fully the generation of
stub code for interfacing with Java or .NET, while this is not
possible in C.  To generate stub code, you need to know quite a lot
about the library you're interfacing with: 
- types of function arguments and results, and of data structure members;
- memory protocol (who frees dynamically-allocated memory and when?)
- error reporting protocol (e.g. return "impossible" results, or
    longjmp() somewhere, or call a user-provided error callback, or ...)

For C, most of this information is implicit or written down in English
only.  E.g. the function prototypes you find in .h files are wholly
inadequate to generate stub code because the C types are not
informative enough: is "char **" an array of strings or a string
result passed as an "out" parameter?  what about macros (they are in
effect untyped)?  As for memory management and error reporting, the .h
file doesn't say anything at all.  

So, interfacing with a C library requires quite a lot of manual
intervention to supply the missing info.  This can take the form of
writing the stubs entirely by hand, or writing a higher-level
description of the library interface in an IDL-like interface from
which the stubs can be generated automatically.  The latter means less
typing, but is not actually significantly easier: the programmer still
has to get the intended behavior from the English documentation, and
then shape it into an IDL file that the stub generator will
understand.

Interfacing with Java or .NET is a completely different story:
- Libraries always come with detailed type annotations (descriptors
  in Java .class files; metadata in .NET) that are high-level enough
  to support the automatic generation of stub code.
- These systems are garbage-collected, so there is no concern about
  manual deallocation.
- These systems have built-in exceptions, which most libraries use
  consistently to report errors.

So, the goal of generating stub code entirely automatically can be
achieved with Java or .NET, but not with C.  (Or so I hope; we'll see
how it goes.)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr