On 12 Jan 2004 17:03:28 -0500, Jim Blandy <xxxxxx@redhat.com> wrote:

>
> 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.

That wasn't meant in that way. There might be several implementations
providing similar functionality. But there are certain "basic"
facilities, where, when provided in too many ways, portability
actually suffers. Consider the effort wasted when porting a large
C library (like GTK+) to a single FFI SRFI - while neglecting all
implementations that support a different FFI SRFI.

>
> 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.

Indeed. That's what I'm saying.

>
> 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.
>

I did never suggest such a thing. This SRFI is a special case.
It is (in it's current form) simply too ambitious, while providing
too little abstraction and portability.

cheers,
felix