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

[Rob Browning]

G-wrap is in need of both some minor fixes and perhaps a major
overhaul.  The minor fixes are to make compatible with guile 1.6, but
after using g-wrap for a while in its latest incarnation, we've begun
to feel that some redesign may be in order.  However when I started
thinking about this question, I began to wonder about the bigger
picture, and to wonder if the continued existence of an g-wrap is
actually the best solution.

Overall, I'd like to see what everyone else thinks about this issue
because I'm going to have to do something, and I'd rather expend my
efforts on whatever is the most appropriate solution, presuming we can
settle on one that will still work well with Gnucash.

As it stands now, g-wrap lets you automatically generate C function
wrappers from a imperative scheme-form spec of the function's API.
Something like this:

  (gw:wrap-function some-module
   ;; the Scheme function name.
   'scm-do-something
   ;; the return value
   '(<gw:m-chars-callee-owned> gw:const)
   ;; the C function name
   "c_do_something"
   ;; the arguments
   '((<gw:int> x)
     (<some-strange-type> y)
     ((<some-other-type> gw:const) z))
   "Do something to the int x, the strange-type y, and the constant
   other-type z and return a string that was created via malloc and
   should be considered owned by the callee.")

This isn't actually all that complicated.  The complexity lies in the
specification (which g-wrap also supports) of the types listed here
for the arguments and the return values.  When you define a wrapped
type, g-wrap lets you specify exactly what code gets generated for the
c<->scheme conversions, c-side initialization code, argument checking
code, etc.  What you can specify is *very* flexible, but unfortunately
that also makes *how* you specify it somewhat complicated.

G-wrap isn't doing anything you couldn't just do by hand using
libguile and the appropriate gw_ and scm_ calls; it's just automating
some of the process.  Further, guile already has some tools (the snarf
tools among others) that already help make defining guile functions
from C easier.

THE QUESTIONS:

So the first question I'd like to ask is does Guile need a wrapper
generator at all?  If so, does it need an independent one, or would it
be better suited by improvements to its existing infrastructure for
wrapping functions, better documentation of the process, and an
extensible way to define/add "wrapped c<->scheme types"?  One argument
in favor of the " drop g-wrap and just enhance Guile" approach is that
it *might* mean that we could come up with a much more interesting
solution, one that integrated much better with GOOPS, smobs, GC
issues, etc.

Another possibility would be to consider dropping guile in favor of
SWIG and just working to make sure Guile's SWIG support is
sophisticated enough to provide a really good solution.  Last time I
looked at SWIG (which was admittedly a while ago), it wasn't flexible
enough to do what we needed, and I didn't get any response from their
development community when I asked about enhancing it.  From later
evidence I suspect that may have been a fluke of some kind, and I've
heard that their Guile support's been improving (though I don't think
Guile is listed on their web page).

Overall it seems like dropping g-wrap in favor of SWIG, presuming
that's even an option, would have the advantage of putting effort into
making Guile's SWIG support stronger, but we might end up (as far as
wrapping C functions goes) with a less tightly integrated solution
than we'd have if we stuck with something more guile-specific.  With
g-wrap we've been able to tailor the wrapping of specific types very
closely with Guile smobs or native types using libguile directly.  I'm
not sure that would be as possible with SWIG.

Thoughts?

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