[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Providing an API reference
Re: Providing an API reference
Mon, 24 Oct 2005 10:57:19 +0200
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
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
> I can really recommend reading the paper about the PLT FFI, linked
> from , to see how expressive a Scheme-Level FFI is; hiding it
> below a code generator only takes away from that.
>  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, 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.
However, it seems that many Scheme implementations come with a OO system
very close to GOOPS.
> 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 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
>  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.