Re: [Caml-list] Automatic wrapper generator

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

W liście z sob, 22-05-2004, godz. 23:13 +1000, skaller napisał:

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

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