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: Richard Kelsey <kelsey@xxxxxxx> > I can understand wanting the first FFI SRFI being a safer, more > general one, perhaps based on JNI or Pika. This SRFI isn't that > SRFI because that isn't the type of FFI that Mike and I needed. In off-list conversations about SRFI-50, that paragraph has raised a few hackles. We all know and appreciate that the SRFI process doesn't require authors to respond to the needs or thoughts of anyone else -- they need only conform to the rather slim requirements of the process. But I think we also all know that the SRFI process was designed to encourage and facilitate the collection and application of divergent needs and thoughts. The SRFI process _enables_ the development of rough consensus without trying to _enforce_ the development of rough consensus. It's a kind of "IETF-lite". So I think it is an abuse -- albeit a kind of abuse the SRFI process explicitly declines to prohibit -- when authors say (and I'm not certain that this is what you're saying but it's sure looking that way): "Consensus doesn't matter for this SRFI. My goal is to have a finalized SRFI with essentially the same content as my draft. Your objections are interesting but contradict my goal: I guess we just have to agree to disagree." Now to the specific issues that are causing friction: 1) You say that a Pika-style calling convention "isn't the type of FFI that Mike and I needed." I'm trying to interpret that statement according to the "reasonable person principle". In other words, my first axiom is that it's a statement from a reasonable person rather than just a "Nyah, nyah -- you can't stop me from finalizing." I'm also trying to interpret it as a correct statement. In other words, my second axiom is that "Hey, Mike's a smart guy. Perhaps there's something important about Pika-style conventions that, if present in the FFI, would cause him to be unable to accomplish some technical goal." I'm so far unable to interpret the statement ("isn't the type of FFI...") in a way that is consistent with both axioms. Axiom 1, the "reasonable person principle", is my favorite. I'll keep that one for now. So perhaps the problem is with axiom 2: you're making an honest mistake, not a correct technical judgement. This hypothesis, that you're making a mistake, is reinforced by an experiment that jivera (Matthew Dempsky) carried out. He thought: "Suppose I have a Scheme implementation that uses a Sperber/Kelsey-style FFI. And further suppose that I now want that implementation to have a Pika-style FFI. How hard is that?" About 2-3 pages of trivial code later, and disregarding for the moment the issues we haven't taken up yet about error handling and non-local exits, he had 95% of an implementation. The only sticking point was on the exact syntax of GCPROtect-family macros: it would take some tweaks to reconcile those in Pika with those in the draft. We would need to make a trivial addition to the Pika macros to complete the job. What about in the other direction? I'll ask: "Suppose I have a bunch of code using a Kelsey/Sperber-style FFI -- but the FFI standard is Pika-style. How hard is it to port that FFI-using code to the standard?" I don't have as clear an empirical an answer to that question. On the other hand, I have personally made many similar kinds of global changes to systems in the past. If what you have is a few 10K lines of code, I find it hard to believe that that would take more than a couple of weeks. Emacs is a wonderful thing -- between grep, tags, query-replace, keyboard macros, and a tablet of paper -- conversions similar to this can go pretty quickly. If the code in question is free software of general interest, I bet you could get a decent amount of help with it. So to sum up (1): I am having trouble imagining a respectable "need" for a non-Pika-conventions FFI. Can you elaborate on the nature of this need? 2) Momentum is an issue. The phrase "Sperber and Kelsey FFI SRFI" contains four words that will catch people's attention and give weight to the contents of the document so referred to. The draft, while completely unacceptable for Pika (which isn't even done yet), _can_ be implemented in many implementations. My fear here is that (a) people _will_ widly adopt the draft if finalized; (b) people _will_ write code against it; (c) lack of support for the draft will become a major barrier-to-adoption for future implementations. Therefore, in my view, the draft has a non-disregardable chance of limiting the future of Scheme implementation techniques. Most people, g*d willing, live in the future. Whatever "needs" Kelsey and Sperber have regarding the draft, let's not forget what Spock says: "The needs of the many outweight the needs of the few, or the one." And, anyway, Spock aside -- it's not unselfish to want Scheme to evolve according to its promise. In this case, "the needs of the many" are not necessarily contradictory to "the needs of the few". 3) Pika-conventions have a huge disadvantage. I think I've argued very well for Pika-conventions on first principles. There's one argument I can't make and that argument has the form "Here, look these successful systems already using them." There's another argument I can't make and that argument has the form "Here, look at this document which is easily massaged into a SRFI that specifies them." A radical proposal for reconciling the differences on this list might be: ~ perhaps some of the "rest of us" can help to revise the draft ~ perhaps some of the "rest of us" can help to implement the revised draft in a few implementations ~ perhaps some of the "rest of us" can help to strengthen the revised SRFI by preparing, before finalization, a few C libraries that use the revised interface to create bindings for some popular libraries For example: my gosh, I'd _really_ like to see SCSH running in several different implementations. And isn't there now an X11 binding for S48? I'd like to see that get around, too. Responses? -t