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

[Dave Berry <dave@kal.com>]

> From: Sven LUTHER [mailto:luther@dpt-info.u-strasbg.fr]
> Sent: Thursday, February 15, 2001 12:13 
> 
> On Wed, Feb 14, 2001 at 08:30:51PM +0100, Xavier Leroy wrote:
> > ...it is possible to automate fully the generation of
> > stub code for interfacing with Java or .NET, while this is not
> > possible in C.

I was thinking of the sort of interoperability problems that Xaview listed
in other recent messages.  But he is of course right that generating stub
code for interoperability with C is a hard problem, and is much simplified
in Java, COM (with type libraries) and .NET.
 
> > - types of function arguments and results, and of data structure
members;
> 
> This can be automated by a basic parser tool, isn't it ?
> This is what i started to do with c2caml, but i have no time 
> to continue work on it.

The parser part is relatively straightforward, but there are many
complications.
-- #include files: do you translate each header file separately?  How do you
refer to items translated in #include'd headers?  How do you resolve name
clashes.
-- #ifdef's
-- macros
-- typedefs
-- proprietary extensions
-- pointer types: e.g. is a char* an array, a null-terminated string, a
sequence of null-terminated strings, or an output parameter?

> > - memory protocol (who frees dynamically-allocated memory and when?)
> > - error reporting protocol 

> Anyway, automating this kind of things would perhaps not gain you a lot
for
> the initial stub writing, since you have to provide some info at first to
help
> an automated tool, but once that is done, it would help a lot to keep
track of
> various versions of the same library.

This is true.  If you can specify the necessary interpretations in a file
separate from the headers.  E.g. you could specify that all the char*
pointers in a given header file are strings, except for certain parameters
of certain functions.

The Dylan community have investigated this in some depth, although I don't
know that they have a finished tool.  Harlequin's Dylan implementation
benefited hugely from code that was automatically generated from C header
files.  Although the translations were highly specific to particular header
files, it was still quicker than translating all the code by hand,
especially when it came to regenerating the code.

It would be useful to have a tool that interpreted C header files and
produced IDL files, not just for OCaml, but for all advanced programming
languages.  If this was sufficiently portable, many projects could benefit.

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