> Bradd W. Szonye wrote:
>> 1. The SRFI process is not for preliminary ideas. If there are several
>>    major issues to resolve, you're *supposed* to withdraw the proposal
>>    until you've worked them out.

xxxxxx@freenetproject.org wrote:
> Round and round we go.  I don't characterize the remaining issues as
> major.

If releasing the implementation without them would create a defect,
they're major issues. And some of the remaining issues would create
defects. Therefore, they're major issues. Also, the SRFI process doesn't
even require major issues: active discussion and revisions alone are
sufficient to reject a proposal, because they're evidence of immaturity.

>> 2. Withdrawal is not supposed to delay anything by a year. You can
>> potentially resubmit in 30 days and finalize 60 days after that -- IF
>> you resolve all of the issues that led to withdrawal in the first
>> place.

> Sorry, I was basing that off the flawed 6 month draft period.
> Nevertheless, it would delay concrete collections for two draft
> periods + 30 days, assuming the second draft didn't run into a
> similarly vehement opposition.

Why not submit the naming standard and the concrete collections
simultaneously, then? Personally, I think it would be better to just
propose the concrete collection SRFI and let it create a de facto
standard for naming. Have you ever heard of a naming standard that
succeeded without a concrete implementation to "sell" it?

> I see it as a tremendous loss to withdraw an SRFI which is largely
> complete and of such utility to the Scheme community.

Without a concrete implementation, it isn't "largely complete," and
you're *vastly* overstating the value of naming conventions per se.

>> 3. The desire to get a SRFI finalized and to build on it is *not* a
>> good excuse to rush into finalizing an immature proposal.

> I agree with everything here except for the immaturity assertion which
> time and time I've said is your subjective opinion.

That's because, once again, you're ignoring the evidence and the
objective standards used to define it. SRFI-44 is immature according to
SRFI process guidelines. It's immature according to any reasonable
standard.

Is it stable? No, it's been revised recently.
Are all major issues resolved? No, there are still some potential defects.
Has it seen extensive use in a production environment? No.

You keep claiming that it's mature because it's based on other
collection libraries. While the concept of collections may be mature,
the SRFI-44 implementation of them is not. (Assuming that you're even
willing to call it an implementation. I'm not.)

>>> SRFI-34 didn't provide a complete package.

>> How so? It's entirely usable on its own. It provides everything that
>> primitive C++ exceptions give you, for example.

> As is SRFI-44.  The Scheme collections provided are entirely usable on
> their own.

What features does SRFI-44 add that we don't already have? A standard
naming convention? That's not compelling. Enumerators? They already
exist as part of SRFI-1 and SRFI-13. Some vaguely-specified
polymorphism? The cost isn't worth the benefit.

SRFI-44 does not have sufficient features to stand on its own as an
implementation. It's a coding standard.

> Nor will future collections be necessary for SRFI-44 to be useful.

You're joking, right? I'd much rather use SRFI-1 and actually get a rich
set of features for dealing with lists than use SRFI-44 to get a small
handful of primitives that I could write myself more quickly than I
could figure out how SRFI-44 works.

> To be sure, thats not largely the point of the SRFI, but I don't
> believe that conflicts with the spirit of the process, to advance
> portable features beyond what is in R5RS.

Where are the advancements? Quit pretending that it's more than a coding
standard and a vague specification of polymorphism. As Tom pointed out,
the polymorphism part is actually *disadvantage* for implementors,
because it's underspecified and difficult to implement.
--
Bradd W. Szonye
http://www.szonye.com/bradd