Re: [Caml-list] Automatic wrapper generator

[skaller <skaller@users.sourceforge.net>]

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