Re: [Caml-list] Possible use for camlp4

[Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>]

From: John Max Skaller <skaller@ozemail.com.au>

> The idea is a file of hand written bindings which generate the C code
> necessary to wrap a C library. There are two outputs: the C glue code
> and the ocaml binding definitions.
> 
> The point is to use camlp4 to make it easier to write the C glue code,
> by inventing some language syntax which knows about the garbage
> collector, heap format, the macros needed to do all that, etc.
> 
> That is, the glue code isn't generated *automatically* from a C interface,
> like with SWIG. Instead, you have to write the glue code by hand,
> as you do now. The difference is that you write it in  a slightly
> higher level language than the ugly and error prone C/Ocaml macros
> system. In addition, the 'simplified' way of using those macros is sometimes
> very inefficient. [eg, making parameters and local variables gc roots
> when there is no need]

Why not.

> If there is one thing that Ocaml is perceived as needing more
> than anything else for industrial use, it's bindings to more C libraries.
> At present, writing them is very very expensive, and maintaining
> them is an even worse problem if the target C library is evolving
> eg GTK. So .. why not use ocamlp4 to help reduce the problem?

This can help, but a frequent misconception is that gluing is the main
problem with external libraries.
It is for beginners, but for experimented programmers, with a good set
of C macros and sane habits, that's the easy part.  Even cooperating
with the GC is not that hard (as long as you don't try to optimize too
much).

What is really difficult is fancy callback systems, and abstracting
the invariants from the C API (including allocation problems).
Both are hard problems, with very little automated support.
In both cases you must understand how the library works from informal
explanations (or quite often reading the source code) before starting
to code. If the library is very regular, or uses a specific language
like Tcl/Tk, you may end up with some way to speed-up the process, but
in general you need to go into details, and there are exceptions.

So, yes for making things easier, like ocamlidl does already for
instance, but there are no miracles: as long as the external world is
not strongly typed in a language we can understand, the process is
going to be painful.

      Jacques Garrigue
-------------------
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