> From: Richard Kelsey <xxxxxx@s48.org>

    >    From: Tom Lord <xxxxxx@emf.net>

    >    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