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.
Anton van Straaten wrote: > To be honest, when Bradd first started raising serious objections, it > was done in such a strident manner, by someone I was unfamiliar with, > that I was inclined to ignore them on the assumption that if no-one > agreed with him, the issue would die down. It now looks as though > that didn't happen... My apologies for my blunt manner. Tactfulness is not my forte. And honestly, had there been no other objections, I too would have assumed that the consensus was against me, that my objections were matters of personal taste and not really major issues. But as you say, that didn't happen. > It seems to me if there's going to be major contesting starting at > this late stage, there's a case for having some substantive discussion > about it before simply withdrawing the SRFI. The SRFI process does specify a discussion period of at least 15 days after any revision. However, it also recommends withdrawal after the third revision to the proposal. There have already been at least two major revisions (iterators to enumerators, and the recent changes). Also, my issues include SRFI-44's failure to meet the basic requirements of 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. 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. > Otherwise, a precedent is created in which the SRFI process can be > sabotaged by sustained last-minute attacks. I agree that last-minute sabotage would be a bad thing. However, keep in mind 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). > I've been monitoring this SRFI loosely since at least May, but > unfortunately, haven't had time to filter the meaningful content out > of the flurry of low-signal-to-noise-ratio activity over the last week > or so. I'm looking at it now. My apologies if I've shed more heat than light. -- Bradd W. Szonye http://www.szonye.com/bradd