Re: [Caml-list] Re: Common IO structure

["Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>]

W liście z śro, 05-05-2004, godz. 18:11 +1000, skaller napisał:

> 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?

-- 
   __("<         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