Re: [patch] subordinate SMOBs with GOOPS superclasses

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> 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.