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> > From: Tom Lord <lord@xxxxxxx> > 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." > No, that is not at all what I was trying to say. I'll try again. I was really trying to leave plenty 'o room for a reply that starts out that way. > At this point I can see four different ways of proceeding: > (A) Rewrite SRFI-50 using either Pika-style or JNI-style > during the SRFI discussion period Big task and I wonder if maybe you wouldn't like some help from others if that's the way to go? I don't see this as all that different from your (C) option -- that's just a minor distinction of process. The phrase "during the SRFI discussion period" strikes me as a minor concern with many reasonable workarounds. One way or another, an FFI SRFI would do well if, at finalization time, it was already running on a few popular implementations and had some interesting libraries using it. It would be nice if we could get that done, too. > (B) Address as many of the issues that have been raised as is > possible while leaving SRFI-50's style intact Obviously I'm not too fond of this, personally. > (C) Withdraw SRFI-50 from consideration until after there > is separate SRFI describing a more general and more > portable FFI "Withdraw and retry" or "extend" or whatever. This draft has from my perspective sparked a needed conversation. I'd like to see a widely acclaimed Scheme FFI grow out of it. I'm 98% confident that, if it would be useful, I can ask some people who contribute Internet infrastructure (hosting services) to the arch project to let me dedicate some of that for this. A not-bad way to understand the Pika Scheme project is as an implementation project that has led off in its entry to the world by trying to nail the FFI issues first. There's more to Pika than that but that's a big part of it. It would not hurt and probably help Pika if I try to lead it in this direction for a little while. Basically, I'm saying that I would lend whatever support I can to to a mixture of (A) and (C). > (D) Withdraw SRFI-50 permanently Nah, let's strike while the iron is hot. > (A) is not possible because time is too short. It took Mike > and I a long time to produce the original SRFI-50 draft and > that was after an even longer period working on and using the > original implementation. I have much less experience with > JNI-style and none at all with Pika-style. > (B) would be my choice, especially because I think that we > could now come up with a much better characterization of what > SRFI-50 is and is not intended for than exists in the > current draft. > I very much doubt that any amount of additional discussion would > switch my preference to (D). > So what I want to know, in an attempt to locate some consensus, > is whether the folks that have been objecting to SRFI-50 in > its current form would be happy (or at least significantly less > unhappy) with (C). I would be very happy with (A+C) and not at all with (B). My _guess_ is that we can get people to help make an (A+C) approach very successful. -t