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.
Date: Mon, 12 Jan 2004 22:13:02 +0100
References: <E1AeyBj-0005Cs-00@xxxxxxxxxxxxxxx> <opr1navdgcw2xcd0@xxxxxxxxxxxxx>
On Mon, 12 Jan 2004 05:31:51 +0100, felix <felix@call-with-current-
continuation.org> wrote:
But, if we end up with a multitude of different SRFIs, addressing
common functionality (this reminds me of SRFI-0 vs. SRFI-7, BTW), we
have gained nothing.
My take on the SRFI process is that it gives two separate
mechanisms for arriving at common interfaces. One is the
discussion period, where the authors of a SRFI get feedback
and get an chance to ammend and improve a particular SRFI.
The second mechanism is that there can be multiple SRFIs
that address a particular problem, giving people a chance
to try out different solutions and see what works for them
and what doesn't.
Some of this stuff is hard and no one understands it well
enough to produce the be-all and end-all of a SRFI, even
with the help of a few months of informed discussion by
experts.
For example, there are lots of different approaches to
threads that differ in big ways and small ways. SRFI-18
describes a fairly standard thread mechanism. But there
are also engines, ERLANG-style threads that don't share
mutable state, cooperative multitasking, non-blocking
synchronization, etc. It would be awful if the existence
of SRFI-18 stopped people from trying out and producing
SRFIs for other thread models.
Obviously this doesn't apply equally to all SRFIs. One
form of nested multi-line comments (SRFI-30) seems adequate
to me.
So where does SRFI-50 fit in this spectrum? Opinions differ.
It clearly isn't universal, but then it never was intended
to be. As far as I know, the notion that a SRFI should
necessarily be portable to all implementations appeared for
the first time in the SRFI-50 discussion. It certainly came
as a surpise to me. (Which isn't to say that it doesn't have
validity, he added quickly in a (probably useless) attempt to
forestall strongly-worded objections to what is a description
of a past event and not intended as a value judgement.)
The genesis of SRFI-50 is simple. Scheme 48 had a extremely
minimal C FFI. Mike needed something more. He and I developed
an FFI that we found quite useful. We thought others might also
find it useful, so we put some work into fleshing out the parts
that we hadn't needed ourselves and wrote it up as a SRFI. That
we weren't completely out of our minds is born out by Jim Blandy's
realizing that he had already implemented a SRFI-50-like interface
that he planned to at least partially expose to the public.
But that was then and now is now. I'm going to take a day or
two to talk to Mike offline and think about how to proceed.
-Richard Kelsey