Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> From a _very_ quick look, my impression is that the PLT FFI is about > equivalent in complexity and function to what the code generation side > of G-Wrap provides. > > If that's correct, then the key practical difference is that G-Wrap > does everything at build/compile time, where PLT FFI does everything > at runtime -- in which case, surely G-Wrap is the better option? I don't know about the complexity of PLT's FFI, but I do know about that of G-Wrap. ;-) First, code generation in G-Wrap is complex (spread over a number of places, each of which as to be somewhat aware of what the others do) and fragile too. Second, to accommodate different use cases, such as different memory management schemes, G-Wrap has to build in a lot of tricks: the `caller-owned', `callee-owned' and `aggregated' typespecs, not to mention `out' arguments. All these contribute to the code generation complexity. With a Scheme-level FFI, you could implement these semantics (and possibly others) in Scheme. For example, `caller-owned' and `callee-owned' are easily handled by calling libc's `strdup' et al. or whatever it takes to do the right thing. The `aggregated' typespec can be achieved using guardians, for instance. The FFI could simply provide a "C pointer" SMOB; typing can then be done by the bindings themselves, e.g., by wrapping C pointers into structs of whatever. This way, the FFI would only provide basic mechanisms, on top of which a variety of bindings can be implemented in Scheme. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-devel
