This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> As Tom pointed out, the current SRFI draft---even though it may not be
> suitable "standard" material---has a few advantages.
> - Many (but not all) Scheme systems can quite easily support it,
> because it already matches the FFI they have currently.
There are two kinds of "support" that you might mean:
1) These systems can easilly be extended to provide the draft-style
FFI. Code that correctly uses the draft-FFI can run on these
systems.
But Jivera's experiment has already shown that if a system can
easilly support the draft-FFI, then it can just as easilly support
a Pika-style FFI. So I don't see how the draft has an advantage
here.
2) These systems contain libraries, using their native FFI which
can be easilly ported to any system that supports the draft-FFI.
I'm skeptical about that claim: many systems use conservative GC
and provide native FFI facilities that do not correspond to
anything in the draft-FFI.
If there's a claim here that (a) there's a lot of desirable code
already using the draft-FFI and (b) it would be prohibitively
expensive to modify that code to use Pika-style: well, what is
that code? Can we identify and quantify it? Where can I get
some samples of it to take a look at?
> - There's lots of experience with this kind of FFI, and it's proven
> to work (for Scheme systems supporting it) for hooking up a wide
> variety of C libraries.
Lots? Really? You might be right but I'd like to hear more
specifically what you mean. For example, are you counting
FFIs that rely on conservative stack scanning as "experience with this
kind of FFI?"
> - There's a lot of binding code out there that uses this style of SRFI
> which could easily be changed to actually build on the SRFI and
> could thus be easily more portable (if not completely portable).
I'd again like to see those libraries identified and quantified so
that we know what were talking about in this area. I know something
about the internals of Guile and this morning I looked at how
extensions in C are written for PLT scheme. Because of GC issus,
extensions for those systems would require (non-trivial) review and
modification before they would be correct uses of the draft FFI.
In such cases, I see no advantage for the draft here. Just the
opposite: converting such code to the calling conventions of Pika
provides an excellent way to identify places where it is currently
reliant on conservative GC.
> - No existing, released Scheme system I know except for the JVM-based
> ones supports a Pike-style or JNI-style FFI.
You make it sound like the difference between the draft and Pika-style
is _so_ huge that Pika-style is some kind of radical excursion into
wildly unknown and unpredictable territory. I'm having trouble
understanding why.
It seems to me that the difference between the two calling conventions
and value representation conventions are fairly small (but
significant): a slight relocation of an abstraction barrier.
You make it sound like there are many systems using something
syntactically similar to the draft FFI and not relying on conservative
GC. I'm not so sure that there are.
> - A Pika-style or JNI-style FFI could be built on top of it, and it
> could be built in a portable manner.
As you know, this would help systems that already use the draft FFI
but now want to support Pika-style. But doesn't the fact that such
layering is a fairly easy exercise undermine your other claims about
accumulated experience with the draft and ease of porting? Doesn't
the fact that such layering is easy draw into question the value of
posting the draft-FFI as an intermediate step?
-t