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