Re: Future of g-wrap (and guile wrappers in general).

[Rob Browning]

Matthew <address@hidden> writes:

> Working directly with the "scm_/gh_" functions was very time consuming
> and repetative.

This is true, though I wonder how much easier it might be if we add
better docs for the scm_ interface and some of it's fairly helpful
type-checking/error-reporting/all-in-one funcs/macros, and then add
some more help functions/tools where needed.

> Next (actually, this was all very much in parallel) I tried to work
> with g-wrap, because I had it installed, and because Gnucash uses
> it. I had a few problems with this; firstly, I found it difficult to
> understand how the wrapper specification worked [possible reason: the
> documentation is incomplete, or more likely, I'm just not too bright
> :) ].

Nope, it's not you.  In part because g-wrap tries to be so flexible,
it's also fairly complicated and/or confusing.  Couple that with only
partially complete docs so that you have to (at least in part) learn
by example and you've got a recipe for frustration (That's one of the
main reasons why I brought all this up.  I'm trying to figure out
whether or not g-wrap is worth fixing/fully documenting, or if that
energy should be better spent taking what I've learned and applying it
to Guile or SWIG.)

> Once I had this figured out, it was still quite time consuming to
> specify the functions and types. The third concern I had was that it
> needed a g-wrap runtime library, and I didn't want to add
> dependancies to my application. It was obvious that g-wrap provided
> fine control over how the wrappers and types were created, but
> _most_ of the time, I didn't need it.

Agreed.  That's one of the things I was thinking about.  If we do
decide to keep g-wrap, I'll be trying to figure out how to have a
simpler interface/spec for the common cases so that you only have to
whip out the arbitrarily complicated wrapping features when you really
need them.

> It is mentioned at least twice at http://www.swig.org . It's not
> anywhere near as heavily documented as the Perl, Tcl and Python stuff
> though :(

Hmm.  I must have missed it (apologies to the SWIG folks for the
error).

> To, er, wrap up, I'd love to see work done to make SWIG work better
> with Guile (for one, the generated code compiles with pages of
> warnings!) rather than have to choose between close Guile control
> (g-wrap) and sheer ease of use (SWIG),

I think I'll need to look more closely into the current state of SWIG
then.  I suspect there may be a tension though, between the
flexibility you might want wrt Guile specific features and what SWIG
has to require of an interface that must to support so many languages.

Last time (which was a long time ago) it was hard to do things like
define a new type that could define and initialize module specific
static data (or call one-shot initializers).  In general wasn't super
flexible about where you could insert code into the wrappers that were
being generated, though perhaps that's changed, and if not, perhaps,
presuming we really do need more flexibility than SWIG offers and that
the SWIG people are interested in the relevant changes, I could see
about adding whatever's missing.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD