Re: Taking the defs file issue

[Marius Vollmer <mvo at zagadka dot ping dot de>]

Rob Browning <rlb@cs.utexas.edu> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > I quite strongly disagree with this.  In my view, the functions
> > exported to the Scheme side must not be not be `dangerous' in the
> > sense that a pilot error can not lead to memory corruption, memory
> > leaks or similar.
> 
> Well, I suppose this depends on your perspective, and what you want.
> If you want to create a tool that lets you do from scheme the same
> things you can do from C with a given C API, and if you want to
> provide a way for people to *quickly* wrap *existing* C APIs without
> having to write a lot of additional glue code, then I think it's going
> to be *very* difficult to avoid the "dangerous" things you're talking
> about.

Yes, very true.  I guess my main point is that I don't want guile-gtk
to degrade when switrhcing to g-wrap.  That is, the work of avoiding
"dangerous" things has been done (more or less) and I don't want to
lose this.

Well, I might argue that providing a tool that makes it really easy to
do dangerous things is not a good thing, and that we at least should
put up warning signs all over the place that the quick solution is not
necessarily the best solution and that people should spend a moments
thought on how they can make the bindings safer etc.

> As you pointed out, you had to change Gtk+ to make it safe, and in
> general, requiring universal safety may often require the
> wrapper-spec-writer to add "safe functions" on top of an existing C
> API before publishing to scheme via g-wrap.

Yes, and the problem with Gtk+ was that you could not add these safe
functions on top of the existing API.  That would have been nice.

From a broader perspective, makeing an existing API safe for wrapping
from Scheme should almost always be a significant improvemt of the API
itself, independent from Scheme.  A non-trivial client of the API
should have most of the same problems that a Scheme binding has when
it comes to memory management (type issues are probably different).
For example, ref counting in Gtk+ was inadequate, not just for Scheme,
but for any non-trivial program.  You could just not rely on it
because it interacted badly with the functionality of the objects (for
GtkObjects) or wasn't there at all (for GdkFonts etc if I remember
right).

Cleaning up reference counting made the Gtk+ API better in my view,
independent from the fact that I needed the improvement for the Scheme
bindings.

Anyway, we can not always change existing APIs and I got lucky that
the Gtk+ people have listened to me, but I'd still like bring this
topic up.  I also see it as a kind of education.  There are just too
many crappy APIs out there that just don't need to be that way.  API
design is significantly harder than mere coding and I'm unhappy with
most of the APIs.  Just look at libc.  Horrors!  :-)

Ok, well, I guess I don't need to lecture you, but I couldn't help
myself.

> However, I still worry that it may be hard to come up with a safe and
> efficient scheme side interface for every C API without a lot of
> effort, and in some cases, just having the API might be better than
> having the perfect one.

Yes, but when the API allows a safe binding, g-wrap should be prepared
to generate one.  This is probably mostly an issue of documenting what
exactly a safe binding would be.  How to bridge the Scheme / C gap.  I
feel that for all my rambling, I should really sit down and write such
a thing...