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 RAA31892; Wed, 5 May 2004 17:48:24 +0200 (MET DST) 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 RAA31857 for ; Wed, 5 May 2004 17:48:23 +0200 (MET DST) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i45FmJSH006035 for ; Wed, 5 May 2004 17:48:22 +0200 Received: from qrnik ([192.168.0.1] ident=qrczak) by qrnik.knm.org.pl with esmtp (Exim 3.36 #1) id 1BLOd8-0006ZS-00 for caml-list@inria.fr; Wed, 05 May 2004 17:48:18 +0200 Subject: Re: [Caml-list] Re: Common IO structure From: "Marcin 'Qrczak' Kowalczyk" To: caml-list In-Reply-To: <1083744695.20722.1056.camel@pelican.wigram> References: <20040503061212.GA64216@server.vns.oc.ca.us> <40980BA2.1010102@socialtools.net> <20040505.075919.41627374.yoriyuki@mbg.ocn.ne.jp> <1083744695.20722.1056.camel@pelican.wigram> Content-Type: text/plain; charset=ISO-8859-2 Message-Id: <1083772098.5228.32.camel@qrnik> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.7 Date: Wed, 05 May 2004 17:48:18 +0200 Content-Transfer-Encoding: quoted-printable X-Miltered: at concorde with ID 40990CC3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 marcin:01 'qrczak':01 kowalczyk:01 qrczak:01 swig:01 python:01 python:01 api:01 non-trivial:01 bignums:01 implemented:01 -or-:99 api:01 hand-written:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk W li=B6cie z =B6ro, 05-05-2004, godz. 18:11 +1000, skaller napisa=B3: > has been built into Felix as an initial step > in Felix being able to process C library header > files *directly* without binding specifications > or use of an external tool like SWIG." I don't believe it's possible to automatically generate a reasonable binding to a C library, given only its headers. Except very simple libraries. I've recently make a binding between my language and Python. I'm very happy with the result, objects are automatically wrapped or unwrapped or converted, but it would not be impossible to generate this automatically, treating Python as a C library (which it is). One thing which is enough to prevent this is Python objects' reference counts. Of course a good binding must integrate this with garbage collection. Each Python API function is documented whether it steals a reference to arguments (rare) or not, and whether it returns a new reference or not (it often doesn't return a new reference when it always returns a subobject of another object). This is only explained in the documentation, so no automatic tool will handle that. Other than that, it's a non-trivial work to match the conventions, e.g. let Python sequences fulfil sequence protocols in my language and vice versa. Even the simpler thing, converting types, is not easy. A tool will not guess that I want to automatically convert Python ints and longs into INTs in my language, and vice versa; they use entirely different representation of bignums, so a meaningful conversion must be implemented manually. And it will not guess how to match mixed ISO-8859-1 / UTF-32 strings in my language with mixed local byte encoding / UTF-16-or-32 strings in Python. It will not create a Python type which wraps arbitrary objects of my language, nor vice versa. Especially when the objects should translate arguments when they are applied, and translate attribute access. And a tool will not handle translation of exceptions, such thatthey are automatically propagated with appropriate wrapping and unwrapping. But when I finally manually did all this (it took a couple of days; well, it's not completely finished yet), I got a Gtk+ interface for my language completely for free, because someone once wrapped Gtk+ for Python. And similarly many other Python libraries are now directly usable. An API expressed in Python, as opposed to an API in C, is possible to be translated into another language quite well even with no hand-written description. Perhaps many libraries would be somewhat simpler to bind to than the Python API, but I don't believe in an automatic tool for C libraries. Too many issues are visible only in the documentation; it's not possible to know how to map a void* argument. > It took 4 hours ONLY to complete the repackaging > and Cil's frontc parsed the (huge and arcane) > gtk+2.0 header without an error, pretty printing > the parse tree in a neat format. Ok, parsed. Then what? --=20 __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ ------------------- 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