Hi Andreas, Andreas Rottmann <[EMAIL PROTECTED]> writes:
> I've merged that patch now into the development branch. Which branch are you talking about? [EMAIL PROTECTED]/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. _______________________________________________ g-wrap-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/g-wrap-dev
