Re: Providing an API reference

[Ludovic Courtès]

Hi Andreas,

Andreas Rottmann <address@hidden> writes:

> I've merged that patch now into the development branch.

Which branch are you talking about?
address@hidden/g-wrap--dev--0' doesn't seem to be the one.

> I greatly appreciate your involvement. Sorry for being a bit slow to
> comment on the patches not merged yet, instead here are some random
> notes about my ideas about G-Wraps future and C-binding helpers for
> Scheme in general:

Thanks for this discussion!

(But note that I'm still interested in having feedback about the other
patches.  ;-) )

> I'm not at all convinced my effort to make G-Wrap support Scheme 48
> makes much sense at all, for these reasons:
>
> * Most of G-Wraps complexity stems from C code generation, which is
>   not necessary with a Scheme-level FFI, such as Scheme 48 and PLT
>   Scheme provide. It seems a different, more simple tool, with the
>   different features would be much more suitable:

I have doubts about an FFI-only approach, that is, a run-time approach.
I agree that this may be very convenient.  However, I'm afraid that this
may slow things down: it adds a level of interpretation.

For the very same reason, I'm not too keen on the use of libffi in
G-Wrap.  G-Wrap's run-time ends up constructing C function calls at
run-time while it could have generated them when generating wrapper C
code.

>   I can really recommend reading the paper about the PLT FFI, linked
>   from [0], to see how expressive a Scheme-Level FFI is; hiding it
>   below a code generator only takes away from that.
>
>   [0] http://community.schemewiki.org/?ffi

Yeah, I definitely need to look at how this is done in practice.

> * Now that my focus has shifted from Guile to Scheme 48, and
>   portable Scheme in general, I view my rewrite using GOOPS
>   ambivalently; the rewrite has certainly made G-Wrap more flexible
>   and extensible, and probably given it a clearer structure,
>   however, due to GOOPS' use of keywords (while they are
>   R5RS-compatible and supported by some other implementations),
>   GOOPS is fundamentally non-standard, without touching the core of
>   implementations that don't provide #:foo-style keywords it isn't
>   possible to implement it on other Schemes. IMO, G-Wrap supporting
>   multiple back-ends only makes sense when it also is able to run on
>   these implementations, or else it probably won't get much usage.

I'm also no longer a fan of GOOPS.  As I mentioned in an earlier
post[0], I think it makes it quite hard to read and debug the code.
Actually, I'm no longer convinced by CLOS-like object systems, although
I used to be very enthusiastic about it.  I recommend the reading of
Paul Graham's essay on that topic[1].

However, it seems that many Scheme implementations come with a OO system
very close to GOOPS.

[0] http://lists.nongnu.org/archive/html/g-wrap-dev/2005-08/msg00002.html
[1] http://www.paulgraham.com/noop.html

> So in short: G-Wrap's future looks brightest when staying a Guile
> (-only) tool;

Ok.  I think we really need to document it and make it more stable.  I
don't mind if it's not the brightest approach to binding but I think it
really needs to be made more robust.

[...]

>   * Supplement that with tools that can extract the low-level C API
>     information from headers, by parsing and compilation (as outlined
>     above). Also G-Wrap could profit from a C header parser, as
>     writing the declarations for the wrappers is quite tedious if more
>     than a few functions are involved. I haven't really looked at it,
>     but scheffig[1] is a tool that looks similiar to G-Wrap on a
>     superficial level (generates C wrapper functions) and leverages
>     the FCC C parser written by Mike Sperber, which probably is quite
>     portable.
>
>     [1] http://blogs.macbay.de/unspecific/stories/5261/

I'm not convinced by this.  Since fully-automated binding generation is
not feasible, then I'd rather go for fully-hand-prepared binding
generation.  ;-)  This is not too much of a problem *provided* the
binding generator makes it easy.

Thanks,
Ludovic.