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

[Rob Browning]

Alex Shinn <address@hidden> writes:

> For example, when we moved from using integers for enums and flags
> to the combined integer/symbol approach of guile-gtk, I had to go
> through and change every function that accepted or returned such a
> value.

Right.  For g-wrap, we actually managed to have a general-purpose
enough type-definition syntax that definining a g-wrap wrapper-type
for enumerations (as a general concept) was fairly straightforward,
and given the def that was written, g-wrap actually handles
enumerations in functions by always returning integers, but accepting
either integers or symbols as args.  It also auto-generates converter
functions that are bound at the scheme level to translate between ints
and symbols, and in the int->symbol direction, it can either return
*a* symbol, or a list of symbols, depending on an optional argument to
the converter (which is only appropriate if a given int is bound to
multiple values).

> So providing a good wrapper from such a high-level language as Scheme
> to such a low-level one as C is very difficult.  The best tool will
> let you automate the redundant parts and override where necessary.

True, though I tended to think it might be worthwhile to just automate
the low-level stuff (basically the raw C interface to scheme binding),
and support default args, and any other fancier bits at the Scheme
level.  i.e. there should be a way to wrap an interface, producing a
module containing all the "raw bindings", and then write another
scheme-only module on top of that that did any massaging before
publishing the API publically.

> As I see it, the advantages of SWIG are that it's very mature and
> well documented, and any wrappers for one language in SWIG are
> fairly close to being ported to another language.  An automated tool
> for creating a SWIG specification isn't really necessary, since SWIG
> uses a variant of C's .h syntax, which can be adapted from the
> library's header file (if the header doesn't work out of the box).

I tend to agree with all of this with the exception that I really
don't like the "I have to be a fully compliant C preprocessor to work"
approach.  Unless the preprocessor really is a fully blown cpp (and it
may well be by this point), then I'd tend to prefer a separate wrapper
spec file with a clean syntax (of whatever kind), though you might
also want to add automatically generating the C headers from the spec
as an option for projects that don't mind having SWIG in the drivers
seat.

> Also people coming from other languages may be familiar with SWIG,
> which will get the up to speed writing Guile wrappers quicker.

True.

> The advantages of g-wrap are that since it is written in Guile and is
> Guile-specific, it is much easier to extend and add features to.
> Also, since the g-wrap definitions are actually a Guile script it is
> easy to add in local extensions and use ad-hoc logic in your wrapper
> generation where needed.

Right.  I think the main question is going to be, "Are there enough
things we might want to do that involve really tight integration with
Guile such that we really need to have a more tailored tool?".

Some of the discussion of the "preprocessor for a precise GC" might be
appropriate to consider here too.  It's interesting to speculate
whether or not that preprocessor might also be used to handle wrapper
generation, while also taking into account the relevant GC issues.

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