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 NAA08283; Thu, 15 Feb 2001 13:14:34 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA08267 for ; Thu, 15 Feb 2001 13:14:33 +0100 (MET) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.6.1]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f1FCEWj12427; Thu, 15 Feb 2001 13:14:32 +0100 (MET) Received: from lambda.u-strasbg.fr (lambda.u-strasbg.fr [130.79.90.63]) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id NAA00666; Thu, 15 Feb 2001 13:13:21 +0100 Received: from luther by lambda.u-strasbg.fr with local (Exim 3.22 #1 (Debian)) id 14TNHO-0007Sj-00; Thu, 15 Feb 2001 13:12:58 +0100 Date: Thu, 15 Feb 2001 13:12:58 +0100 To: Xavier Leroy Cc: Dave Berry , caml-list@inria.fr Subject: Re: [Caml-list] Re: OCaml on CLR/JVM? Message-ID: <20010215131258.A28656@lambda.u-strasbg.fr> References: <3145774E67D8D111BE6E00C0DF418B663ED7AF@nt.kal.com> <20010214203051.A28371@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <20010214203051.A28371@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Wed, Feb 14, 2001 at 08:30:51PM +0100 From: Sven LUTHER Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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