This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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.