Re: Taking the defs file issue

[Rob Browning <rlb at cs dot utexas dot edu>]

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.

I guess this is going to run us right smack into the middle of the
inevitable "flexiblilty vs performance vs safety vs user-burden"
argument, where here user-burden means two different things.  

On the one hand, there's the burden on the "wrapper-spec-writer" to
consider.  If you require that nothing dangerous ever be allowed from
scheme, then the wrapper-spec-writer's job's going to be a lot harder,
and depending on the API, performance may likely suffer.  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.

On the other hand there's the burden on the end-user of the scheme
API.  If you require everything to be safe, their life is probably, in
general, easier, that is unless they just want to translate some code
from C to scheme that already uses the C API successfully, but does it
in a way that while perfect for the C API, doesn't match the "safe"
interface quite right.

Not sure what the right answer is, but it doesn't seem clear-cut to
me.  I could make a case either way...

In the end, if we could design it properly, it still might make sense
to take things in layers.  G-wrap could, at the lowest level, provide
some infrastructure that makes generating the correct glue easier,
even if it's not completely safe, then a safe layer could be put on
top of that that fixes up bits that aren't safe, and then only the
safe functions could be published from the resulting module by
default.

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.

I keep thinking of CPAN and how nice it would be to have some of that
stuff available from guile, and then I think about how much less
manpower we have to implement it, and *that* leads me to think about
g-wrap (or something similar) to help automate the process, and
automatically maintain the result...

Don't get me wrong.  I'd love a solution that was safe, efficient, and
easy on the wrapper-writers.  If we can come up with one, I'd be
thoroughly pleased.

FWIW
-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930