> From: Richard Kelsey <xxxxxx@s48.org>
> 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
