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