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.
Jim Blandy <jimb@xxxxxxxxxx> 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