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 QAA27583; Sat, 22 May 2004 16:19:51 +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 QAA26957 for ; Sat, 22 May 2004 16:19:50 +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 i4MEJmSH029275 for ; Sat, 22 May 2004 16:19:49 +0200 Received: from qrnik ([192.168.0.1] ident=qrczak) by qrnik.knm.org.pl with esmtp (Exim 3.36 #1) id 1BRXLo-0003Hr-00 for caml-list@inria.fr; Sat, 22 May 2004 16:19:48 +0200 Subject: Re: [Caml-list] Automatic wrapper generator From: "Marcin 'Qrczak' Kowalczyk" To: caml-list In-Reply-To: <1085231636.774.250.camel@pelican.wigram> References: <1084869517.19838.409.camel@pelican.wigram> <1085220553.32267.49.camel@qrnik> <1085231636.774.250.camel@pelican.wigram> Content-Type: text/plain; charset=ISO-8859-2 Message-Id: <1085235588.32267.78.camel@qrnik> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.5.7 Date: Sat, 22 May 2004 16:19:48 +0200 Content-Transfer-Encoding: quoted-printable X-Miltered: at concorde with ID 40AF6184.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 low-level:01 swig:01 high-level:01 hand-written:01 low-level:01 hand-written:01 high-level:01 hypothetical:01 doomed:01 python:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk W li=B6cie z sob, 22-05-2004, godz. 23:13 +1000, skaller napisa=B3: > It comes with a guarrantee your hand written one will never have. > It is guarranteed to work. Exactly as the underlying C does. The binding itself - indeed, but code using it is not guaranteed to work :-) It's more easy to make errors when using a low-level binding. > Yes, it is possible to automate a higher level binding. My point is that it's hard to automate. But it can be done by hand. There might be tools which help a bit (like SWIG; I haven't used it). They will never produce a high-level binding without a separate interface description and some amount of hand-written code. > 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. Not quite. There are three ways: 1. Your automatic low-level binding. It is an interface between different object models, and it works, although it might not be most convenient to use. 2. My hand-written high-level binding. It's designed separately for different libraries, and it is often possible to make most of the library functionality available in the target language under proper conventions. This again contradicts your claim; the point is that it doesn't have to be universal, working for all libraries. 3. A cross between the two: a hypothetical universal translator which is written once and produces bindings for arbitrary libraries, like yours, but the code integrates with conventions of the target language, like mine. This is indeed doomed to fail. But with some languages you can come much closer than with C (e.g. with Python, as I did). > 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 it must be designed case by case: - In some C++ libraries the mutability of a given string parameter or result doesn't matter, and it can be converted by value. - In others it does matter, and a C++ string should be wrapped in a Python object. Surely you don't claim that it's impossible to use a C++ library using strings in Python, or vice versa! > The big win here is that you can now write your high level > interface in the target language (with a library of=20 > specially written C utilities to help). Unfortunately in my case it has two problems: 1. My compiler doesn't produce as optimized code as it could. It's not that bad, but dynamic typing make generating good code very hard. 2. Dynamic typing also implies that the binding would be very unsafe. My binding to almost all libraries is safe, because it performs the necessary checks, but a low-level universal binding would be not. Static types can make it somewhat safer. 3. Since some C functionality, like calling functions of varying types, requires compiling new code (or using non-portable hacks), the binding would either have to use macros (which I haven't implemented yet) or be implemented inside the compiler (which requires some work too, perhaps much). It would be interesting to try to make some universal C binding for my language (after macros). I'm leaving considering it for the future. --=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