This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
On Tuesday, Oct 28, 2003, at 17:36 US/Eastern, Bradd W. Szonye wrote:
Also, my issues include SRFI-44's failure to meet the basic requirementsof a SRFI. The late date has very little to do with that. The original proposal did not address compatibility issues, and because of that, SRFI-44 was nearly finalized with an undocumented incompatibility with R5R6 Scheme. It took a risk (by not documenting compatibility issues) that would have become a major defect had a reviewer not caught it.
There _is_no_incompatibility_. R5RS _does_not_specify_ what
{VECTOR,STRING}-SET! return; SRFI 44 does. That is an _extension_
that is _compatible_.
Before you start waving your hands (as if there hasn't been enough of
that on every side of this flame war) about module systems such as
PLT's where SRFI 44 as a module might prove to be problematic, I shall
again state that this is _not_ meant to be a library SRFI. Library
SRFI are 1, 13, 43, et cetera. This is a proposal for both a basic
interface to various kinds of collections and a specification of some
way to write generic operations on generic collection types. One such
operation is *-SET! for sequences. Now, because this is _not_
intended to be a library SRFI, and because the VECTOR-SET! problem is
_not_ an incompatibility with R5RS, PLT could make its own VECTOR-SET!
return the vector: this would probably be a trivial change and would
allow for PLT to stay compatible with R5RS (assuming it already _is_
compatible). Problem solved.
Likewise, SRFI-44 takes risks by not fully implementing the interfaces that it specifies. I'm not willing to accept that risk, especially not after the compatibility problem.
Despite the fact that there have been _plenty_ of other collections APIs from which this SRFI defines, and _plenty_ of implementations of them?
I agree that last-minute sabotage would be a bad thing. However, keep inmind that the SRFI process is about consensus. If it were just me arguing, no matter how vocally, I'd still recommend finalization (so long as the final version met the basic SRFI requirements, which the current draft does not).
What more do you want the SRFI to meet? A concrete collections SRFI is a different beast.