Jim Blandy <xxxxxx@redhat.com> writes:

> But to suggest that a SRFI should not be finalized until there is a
> consensus that it's the right thing is to re-impose the same sorts of
> restrictions that the SRFI process was established to work around, as
> they affected the definition of the language itself.

Well, you can request an implementation without a SRFI.  If the only
point is to discuss, and then publish, then we don't need the process
at all.

I think the question I would like to hear from the authors at this
point is: why should this be a SRFI at all?  How are you being held
back if this isn't finalized?  Or alternatively, what would
finalization give you that you don't have now?

In SRFI 1, for example, there are ready answers: different Scheme's
all feel the need for fancy list functions, and users are helped a lot
if we all try to use the same ones.  Even if we aren't certain that
they are all the Right Thing yet.

Ok, now, for SRFI 50, what's the answer?

Or the horse I like to beat: for another SRFI, it always makes sense
to say "I request that you implement this", because it can always be
done, if at least by making the scheme fancier to accomodate the new
functionality.  But SRFI 50 is a new thing: requesting implementation
is in many important cases, a request that the scheme in question
*dumb itself down*.

Thomas