Re: Thoughts on g-wrap, guile FFI and guile-gnome

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> Hello!
>
> Your insights in reverse:
>
> On Sat 21 Feb 2009 03:52, Andreas Rottmann <address@hidden> writes:
>
>> 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.
>
> I completely agree, this makes sense, and we should do this at some
> point this year.
>
It should be relatively straightforward, and I'm willing to help with
it.

>> I wonder how the advent of gobject-introspection will influence the
>> future of guile-gnome.
>
> I want to switch to it. But this is like a 200 hour project, and with
> less deployment than our existing solution. I don't anticipate working
> on this in 2009.
>
If Guile would support some releveant parts of R6RS, lets say, by the
end of this year, perhaps sbank could be dropped in, and *voila* you'd
have gobject-introspection support :-) (although I admit that this has a
definitly utopian flair). Of course, there would be have to be some kind
of compat layer that provides the GOOPSy interface that Guile-GNOME
provides on top of the sbank substrate (which maps GObject to a much
simpler objects system, which is implementated in just a few pages of
code [0]).

To get more realistic: it might be the case that sbank's design is not
well suited to the way Guile works; a few notable points about it:

* There's absolutely no C code involved, which means it demands decent
  speed from the implementation's FFI (mostly the part that deals with
  access to C-managed memory). This (no C code, and a not-unreasonable
  speed) is accomplished by circumventing (mostly) the "girepository"
  library, which, for the most part, just makes the raw typelib binary
  data available via C "accessor" functions. If you have to go through
  the FFI layer's function call mechanism for each bit of info in the
  typelib, it's going to be expensive soon. So I've decided not to wrap
  libgirepository, but deal with the typelib data myself.

  The more "traditional" approach (taken by all other
  gobject-introspection bindings I know about), is to use wrap some C
  code around libgirepository, which builds up the procedures, classes,
  etc. for the high-level language, from C.

* Its code uses syntax-case (as specified in R6RS) in quite a few
  places. I hope that Guile's macro problems (which currently interact
  horribly with modules) will be resolved at some point, and that it
  will gain full syntax-case support. Can anybody hint at if/when/how
  that will happen?

[0]
    http://download.gna.org/spells/darcs/r6rs/sbank/gobject/internals.sls
    (mostly the code around send-message)

Regards, Rotty