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 UAA28384; Wed, 14 Feb 2001 20:30:54 +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 UAA28435 for ; Wed, 14 Feb 2001 20:30:53 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f1EJUpP18971; Wed, 14 Feb 2001 20:30:51 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA28463; Wed, 14 Feb 2001 20:30:51 +0100 (MET) Date: Wed, 14 Feb 2001 20:30:51 +0100 From: Xavier Leroy To: Dave Berry Cc: caml-list@inria.fr Subject: [Caml-list] Re: OCaml on CLR/JVM? Message-ID: <20010214203051.A28371@pauillac.inria.fr> References: <3145774E67D8D111BE6E00C0DF418B663ED7AF@nt.kal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3145774E67D8D111BE6E00C0DF418B663ED7AF@nt.kal.com>; from dave@kal.com on Fri, Feb 09, 2001 at 03:49:16PM -0000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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