From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA31845; Fri, 16 Feb 2001 19:34:14 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA31948 for ; Fri, 16 Feb 2001 19:34:13 +0100 (MET) Received: from mrwall.kal.com (mrwall.kal.com [194.193.14.236]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id f1GIYCT00551; Fri, 16 Feb 2001 19:34:12 +0100 (MET) Received: from mrwall.kal.com [194.193.14.236] (HELO localhost) by mrwall.kal.com (AltaVista Mail V2.0J/2.0J BL25J listener) id 0000_004f_3a8d_7306_bf85; Fri, 16 Feb 2001 18:35:50 +0000 Received: from somewhere by smtpxd Message-ID: <3145774E67D8D111BE6E00C0DF418B663FD1F3@nt.kal.com> From: Dave Berry To: Sven LUTHER , Xavier Leroy Cc: caml-list@inria.fr Subject: RE: [Caml-list] Re: OCaml on CLR/JVM? Date: Fri, 16 Feb 2001 18:38:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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