Re: [Caml-list] Automatic wrapper generator

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

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.

I'm currently wrapping some libraries for my own language. I have
working bindings to zlib, ncurses, Python interpreter, some Unix API,
and as a rather impractical but instructive example - qsort().

It's a tedious task because I set up high requirements for myself.
Big ints are transparently converted even in case the C library uses
64-bit numbers, memory management is integrated with GC, various error
codes are converted to exceptions, exceptions are propagated through C
callbacks, C enumerations and ints which encode enumerations are
translated in a typesafe manner (my language is dynamically typed,
so it looks differently than in OCaml, but the issue is there too).

More importantly, C libraries which can be made instances of generic
APIs of my language are wrapped appropriately: you can use zlib as a
layer on I/O streams, or treat gzip files with the same API as native
files, use Python collections and numbers together with collections and
numbers of my language, mixed in either environment, and use values
hashed by one language as keys in dictionaries in the other language.

All this seems impossible to be done automatically, and I feel it's
important.

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, interfacing to particular Python libraries
themselves need zero additional code! And they even look quite usable,
modulo lack of matching of additional generic interfaces. I have a
working Gtk+ binding for free because Python people once wrapped it for
Python.

OCaml doesn't seem to use generic APIs with substitutable interfaces too
much, because it's expressed either as modules, which are somewhat
second-class, or as objects, which are quite heavy. For example there is
no place to offer your semantics of arithmetic, to provide a layer of
translation for I/O functions, or a type of a sequence. This is both a
good and a bad thing:
- Poor reuse of code, you can't use standard function on non-standard
  objects, e.g. character I/O works only on raw files.
+ No runtime dispatch, so it's fast.
+ Less work for interface generator :-)

I will try to make a binding between my language and OCaml, but I'm
not sure how should I approach it because OCaml is statically typed.
Perhaps this time I should consider OCaml the "master" side where most
glue code is put in. Objects of a dynamically typed language are easier
to be operated on from other languages.

It will be fun to use Python libraries from OCaml through my language.
I've seen some Python binding for OCaml but it was very poor.

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