felix <xxxxxx@call-with-current-continuation.org> writes:
> 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.

I'm kind of uncomfortable with this interpretation of the SRFI
process.  I think it makes final SRFI's more preemtive of competing
ideas than is helpful to the language.

It's obviously good to avoid gratuitous differences.  So a SRFI's
editors should feel obliged to address as many concerns as they can,
and help the SRFI address as wide an audience as they can.

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.