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.
On 12 Jan 2004 17:03:28 -0500, Jim Blandy <jimb@xxxxxxxxxx> wrote:
felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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