Re: guile-ffi

[Gordon Matzigkeit <gord@trick.fig.org>]

Hi!

>>>>> Marius Vollmer writes:

 MV> 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.

 MV> That's a weak excuse, IMO.

I retract that statement.  I shouldn't have used Moore's Law as an
excuse for ignoring performance issues.

 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. ;)

 MV> Errm, a C compiler is a considerable piece of code, while Scheme
 MV> is a language.  I find it hard to compare the two.

The basis of my argument is the fact that I've played with RScheme.
RScheme is nice in that it puts Scheme in control over C rather than
vice versa.  I dislike the idea of having to ``exit Scheme'' in order
to write or optimize a new module binding.
 
 MV> I agree, that you need a kind of higher-level, formalistic
 MV> description of the functions that you want to wrap.  You can then
 MV> either use this description to construct appropriate calls to
 MV> ffi-create/ffi-call, or you can use it to generate C code that is
 MV> then compiled.

I like this idea.  I think it will be where module systems start
going.

 MV> Up to now, only the static/compiled approach has been
 MV> implemented, I think.

That is the main reason why I'm pressing for focus on the dynamic
approach: we don't need to pay any more attention to the static
approach because there are a lot of people thinking about it.

Let's pay attention to making the dynamic approach work properly, then
integrate it with the static approach that other people like best.

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

Agreed.  My inclination is only to prototype the dynamic approach, and
be lax about integration until we know the issues that are involved.

Prototyping is the buzzword... I think that the ideal system is
different enough from existing static tools that it is fruitful to try
an entirely new direction for a little while.  I think the dynamic
approach needs more work before we (I) will understand enough to start
doing efficient integration.

 MV> My first question then is this: have we enough control over
 MV> low-level details from Scheme?

We may not right now, but there is utterly no reason why we shouldn't
ever have enough control.

 MV> IMO, any decent Scheme binding to a C library must hide the
 MV> explicit resource management of the C API.  Can we arrange for
 MV> this from Scheme alone?

You are right in that we need cooperation of the language in which the
allocation occurs.  However, I think there are some tricks we can use
to give Scheme the ability to manipulate those language's structures
without having to resort to special-purpose code for every new module
binding.

I'm working on hooks to do this.  My approach is highly influenced by
gstep-guile and libguileobjc.  I'll let you know when I have a
prototype that meshes nicely with your GTK dynamic linking.

It's hard to discuss this in specific terms, and I am still a little
wary that my idea may not pan out the way I'd like.  So, I'll
experiment a little, then get back to you.

-- 
 Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
    Lovers of freedom, unite!     \// I use GNU (http://www.gnu.org/)

Copyright (C) 1998 FIG.org; the creator offers you this gift and wants it
to remain free.  See http://www.fig.org/freedom.html for details.
  This work may be copied, modified and distributed under the GNU General
  Public License (GPL).  See http://www.gnu.org/copyleft/gpl.html.