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

[Sven LUTHER <luther@dpt-info.u-strasbg.fr>]

On Wed, Feb 14, 2001 at 08:30:51PM +0100, Xavier Leroy wrote:
> > 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;

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.

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

More difficult, C has no standard way of doing this, but often libraries have
a standard way of handling this.

> - error reporting protocol (e.g. return "impossible" results, or
>     longjmp() somewhere, or call a user-provided error callback, or ...)

Same as above ...

> 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

Yes, this is difficult, just the char * argument type can be a problem, since
it is not possible to know if it is a 0 terminated string or somethign else.

> result passed as an "out" parameter?  what about macros (they are in

Just expand them before analysing the code and writting the stubs. 

You could keep them, and have a special preprocessor that sees if it is
possible to use polymorphic functions instead, as it is often possible, but
for straight 1-1 stub writting, expansion is the right way of doing this.

> effect untyped)?  As for memory management and error reporting, the .h
> file doesn't say anything at all.  

Well, memory management is not easy to do. maybe the addition of a per
function manual intervention, or the fixing of a per .h file or per library
convention should help.

Going beyond that would need the analysis of the whole source code, which i
guess is feasible also (for open source projects), but a bit long and heavy.

That said, this apply only to pointer argument types, as the rest of them are
copied around.

Anyway, automatissing 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.

Friendly,

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