Re: guile-ffi

[Marius Vollmer <mvo@zagadka.ping.de>]

Gordon Matzigkeit <gord@trick.fig.org> writes:

> Yep, but my machine is already fast enough that performance isn't an
> issue any more (since the main hit is in initialization), and it's two
> years old.

That's a weak excuse, IMO.  It wont be very long before the typical
Linux box can compile its kernel faster than popping up the file
dialog box of Netscape. :-|

Of course, a fast machine is important for development.  But it is
always an eye opener to actually run your code on last generations
hardware.

>  MV> Furthermore, I'm not convinced that we can get reliable bindings
>  MV> to C code without the help of a C compiler.
> 
> Anything a C compiler can do, Scheme can do better. ;)

Errm, a C compiler is a considerable piece of code, while Scheme is a
language.  I find it hard to compare the two.
 
> My task is to wrap the entire GNU C library in Guile, and that is much
> too hard to write and maintain static C bindings.

You mean, manually?

I agree, that you need a kind of higher-level, formalistic description
of the functions that you want to wrap.  You can then either use this
description to construct appropriate calls to ffi-create/ffi-call, or
you can use it to generate C code that is then compiled.

I think that one formal description can serve both purposes at the
same time.  Thus, you get dynamic behaviour for interactive
development.  And you get compiled code for those people that care
more about space/time efficiency (because they don't want to change
the decriptions at all).

Up to now, only the static/compiled approach has been implemented, I
think.  Several people have written glue generators.  I know at least
G-Wrap by Christopher Lee, SWIG, and my own Guile/Gtk thingy that is
based on G-Wrap.

Extending these static tools to also cater for the dynamic uses via
libffi is very interesting.

My first question then is this: have we enough control over low-level
details from Scheme?  The scm_ or gh_ interface of Guile that would be
used from C allow considerable more tinkering, especially when it
comes to garbage collection.  IMO, any decent Scheme binding to a C
library must hide the explicit resource management of the C API.  Can
we arrange for this from Scheme alone?

For example, my Guile/Gtk bindings implement a smob for the GtkObject
structure (and its derived types).  This smob has some very specific
code for interfacing Guile's tracing collector to Gtk's refcounting
mechanism.  I think this is hard to do from Scheme alone, especially
as we can not run Scheme code during GC.

I'm sure that every non-trivial C API that is worth being exported to
Scheme poses its own very special challenges that need to be adressed
in very specific ways.

But given that the GtkObject specific are already taken care of by C
code, it would be cool to use libffi to make the rest more dynamic.

>  MV> Tom Lord has interfaced Systas (which is an offspring of Guile, I
>  MV> think) to a C parser.  That could be very helpfull for parsing
>  MV> header files.
> 
> Do you know where I could find this?

He released it as part of the first issue of the ~twaddle d-zine.
Maybe a web search will turn it up.