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 PAA17783; Sat, 22 May 2004 15:14:07 +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 PAA17043 for ; Sat, 22 May 2004 15:14:06 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4MDE2SH023199 for ; Sat, 22 May 2004 15:14:04 +0200 Received: from [192.168.1.200] (ppp114-11.lns1.syd3.internode.on.net [150.101.114.11]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i4MDDvZq084480; Sat, 22 May 2004 22:44:00 +0930 (CST) Subject: Re: [Caml-list] Automatic wrapper generator From: skaller Reply-To: skaller@users.sourceforge.net To: "Marcin 'Qrczak' Kowalczyk" Cc: caml-list In-Reply-To: <1085220553.32267.49.camel@qrnik> References: <1084869517.19838.409.camel@pelican.wigram> <1085220553.32267.49.camel@qrnik> Content-Type: text/plain; charset=UTF-8 Message-Id: <1085231636.774.250.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 May 2004 23:13:57 +1000 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 40AF521A.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 sourceforge:01 2004:99 marcin:01 'qrczak':01 kowalczyk:01 wto:99 hackery:01 usr:01 include':01 isomorphism:01 fallback:01 swig:01 python:01 bug:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sat, 2004-05-22 at 20:09, Marcin 'Qrczak' Kowalczyk wrote: > W liście z wto, 18-05-2004, godz. 18:38 +1000, skaller napisał: > > > With some platform specific hackery, I am now able to > > wrap 90% of all headers in '/usr/include' and execute > > a single Felix test case: > > It's impressive, but I'm afraid a high quality binding to an average > library is impossible to obtain automatically. What you mean is a high *level* binding. The automatically generated one is the very highest quality. It comes with a guarrantee your hand written one will never have. It is guarranteed to work. Exactly as the underlying C does. [And also you can construct it in a few seconds :] > All this seems impossible to be done automatically, and I feel it's > important. Yes. But there are many possible high level bindings. This code generator quite deliberately, and by specification, produces a low level binding. Its aim is to guarrantee an isomorphism between the target language and the C semantics. Yes, it is possible to automate a higher level binding. But it seems wise to get the lowest possible level binding to work first: and to make absolutely sure it can always be made available as a fallback. There is a very important theoretical reasoning behind this: if you try to interface systems with disparate object models your bindings are GUARRANTEED TO FAIL. The reason is clear and contained directly in the assumption that the object models are disparate :) SWIG can't even get C++ and Python strings to work. It never will. It isn't a bug in SWIG either. It simply cannot be done. [Python strings are immutable, C++ strings are not .. this is enough to guarrantee no isomorphism can exist] So beware .. almost every high level binding is certain to be flawed. > I wonder how much the amount of work depends on the source and target > languages. For example although interfacing to the Python interpreter, > written in C, was a big task, Felix binding to Python will work out of the box, meaning the automatically generated one will work. It won't convert Felix strings to Python ones inside the FFI. It won't touch any ref counts. It will do EXACTLY what calling the C API would do. The big win here is that you can now write your high level interface in the target language (with a library of specially written C utilities to help). BTW: to give you an idea of 'low level': the code to drive, for example, GTK, in Felix will actually be MORE COMPLEX than the C. The reason is Felix doesn't allow any automatic conversions, whilst C does. You have to add casts physically where you need them. So this is *really* low level. Deliberately. I don't want to write high level bindings in C. I'd rather do it all in Felix. And ditto for an Ocaml binding: I'd rather do the high level binding logic in Ocaml than try to do it in some arbitrary mix of the two, where a heap of heavy design work is needed to get the boundary just right. Much easier to modify code written in a single language. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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