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 SAA16427; Thu, 16 May 2002 18:20:01 +0200 (MET DST) 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 SAA16435 for ; Thu, 16 May 2002 18:20:00 +0200 (MET DST) Received: from c007.snv.cp.net (h013.c007.snv.cp.net [209.228.33.241]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g4GGJxn16068 for ; Thu, 16 May 2002 18:19:59 +0200 (MET DST) Received: (cpmta 949 invoked from network); 16 May 2002 09:19:52 -0700 Received: from 65.187.194.217 (HELO vaiobambino) by smtp.directvinternet.com (209.228.33.241) with SMTP; 16 May 2002 09:19:52 -0700 X-Sent: 16 May 2002 16:19:52 GMT From: "Jeff Henrikson" To: "Benedikt Grundmann" , =?iso-8859-1?B?Suly9G1lIE1hcmFudA==?= Cc: Subject: RE: [Caml-list] Generating C stubs Date: Thu, 16 May 2002 12:37:33 -0400 Message-ID: <001301c1fcf7$fa7b70c0$d9c2bb41@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020515111328.A13106@fr.thalesgroup.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >> and another one I don't recall (IIRC, someone claimed >> that he was working on a SWIG interface). > > That was me and I'm still working on it. I just No it was me! ;-) Actually I basically did write a SWIG language module. (How is it that we didn't see each others work on the list archives?) Anyway, after writing about 2000 lines of C code but before getting the bugs worked out, I abandoned it. My reasoning was: 1) SWIG is not sophisticated enough to get the behavior I wanted easily. 2) Doing extra work to approach what I wanted was making massive code bloat (SWIG is written in C and is not forgiving of changing the "normal" behavior from the language module end) 3) I hate programming in C, especially when the API has been constructed to treat _everything_ as a void*. 4) Someone released a binding for the interfaces I needed So that put the lid on that one for a while. But I learned why exactly I find it (and the IDL approach, and other FFI systems) inadequate. SWIG tries to be a little bit smarter than IDL by letting you break away from the "this parameter is [in], this parameter is [out]" level of abstraction, by allowing some weak sorts of pattern matching. In other words, it can take the names of the parameters in a C header file and say "make all int parameters named 'point' and convert them this way. But make all the int parameters named 'color' and convert them this other way." But it's not general enough, and still makes the mistake of annotating the header file rather than making the annotations separate. So when version 2.0 of your header files come out, you start from scratch or do some silly diff3 mucking around. I started implementing a new header generator based on the idea of describing the annotations as a caml program. Basically have a bunch of convienience functions that search through a C abstract syntax tree to ask things like this: 1) I need to use function FooOp which takes a datatype Foo*. Read mydefs.h which contains their prototypes into the current environment. 2) Find me all descendant types which are needed to build the struct Foo. 3) Generate me constructor functions to build these ones which I declare to be public members, and any of their children. For primitive types, convert using these C code snippets I give you (ala SWIG typemaps). 4) Find me all functions which take a Foo* as a first parameter. Write C wrappers for them, caml external declarations, and put them together as a class in an OOP wrapper ala lablgtk. Truncate the method names from Foo_happyOperation to just myFoo#happyOperation by a regular expression substitution, with exceptions which I specify by hand. Anyway, needless to say there's a bunch of stuff to be worked out, but I may get back at the project soon, as I am needing another API binding. I really want to short circuit the writing each function by hand as you go thing. The problem is that I usually work with APIs that I don't know upfront, and want to just generate the stubs in bulk and learn the API straight from an ML environment. (This is one of the areas where caml is definitely not as easy as C yet.) I think 95% of the necessary information is already contained in well stylized header files, we just need a way of systematically cleaning up the last 5% into a complete IDL level of knowledge. Two further extensions of such a system would be to 1) produce a language independent output, in other words write out IDL instead of C wrappers. 2) construct a language independent input, so that non-caml programmers might be seduced. :-> Regards, Jeff Henrikson ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners