Thoughts on g-wrap, guile FFI and guile-gnome [was: 1.9.11 ffi reference bug]

[Andreas Rottmann]

[ Sorry for the crossposting, but I think (a part of) the message is
  relevant for all mailing lists I'm sending this to ]

Greg Troxel <address@hidden> writes:

[ Regarding the need for a G-Wrap release, due to a bug ]

>   It is. I've a release tarball ready, will upload this weekend (along
>   with guile-gnome-platform packages for Debian).
>
> Great - glad you are still out there and g-wrapping.
>
Well, I'm still out there, but my involvment in G-Wrap has degraded into
maintainance mode; I'll probably not evolve the codebase
further. However, it seems that G-Wrap is kind of feature-complete as
far as guile-gnome is concerned -- an that's its only client ATM AFAIK,
as gnucash has transitioned to SWIG.

For a different, but related topic: I wonder how the advent of
gobject-introspection will influence the future of guile-gnome. With the
VM branch landing in Guile soonish (and hence improved performance), it
might make sense to provide a pure-Scheme FFI inside Guile core (perhaps
just molding the current G-Wrap runtime library into shape). Once you
have that, you can create bindings without the need for any "binding
generation" step, hence doing away (in principle) the need for G-Wrap
altogether.

For an example how such an FFI would look like, take a look at the PLT
FFI:

http://docs.plt-scheme.org/foreign/index.html

However, I like the Ikarus FFI better, which is more minimalist (and
more in line with both Scheme and UNIX philosophy, IMHO), see [2],
chapter 5.

Note however, that either FFI provides the primitives to emulate the
other (I've built a very Ikarus-like, portable FFI on PLT, Ikarus and
Ypsilon) [3]

Using such an FFI, it is possible to use the typelib data provided by
gobject-introspection to build bindings for e.g. GTK+ almost
automagically (nearly no customization needed for GObject-based APIs). I
have started an attempt to do so for R6RS Schemes (namely Ikarus, PLT
and Ypsilon) [0]. The amount of porting work to another (R6RS)
implementation that provides the necessary FFI building blocks is
trivial[1]. Code written towards the bindings created by this approach
completly portable.

Regards, Rotty

[0] See http://live.gnome.org/sbank

[1] Namely errecting a thin portability layer upon the host
    implementations FFI. The code that does the actual work of handling
    the typelib data and creating the bindings is completely
    implementation-independent.

[2]
http://bazaar.launchpad.net/%7Eaghuloum/ikarus/ikarus.dev/download/head%3A/ikarusschemeusersgui-20081023124504-qudot9ri5pcmiao8-1/ikarus-scheme-users-guide.pdf

[3] See http://download.gna.org/spells/darcs/r6rs/spells/libraries/,
    files foreign.sls and the compatibility layer inside the foreign/
    subdirectory.