Bradd wrote:
>> The SRFI specifies a type which is a bag but which is not a
>> sequence. However, there is no implementation of that type.

xxxxxx@freenetproject.org wrote:
> Thank you, that makes much more sense than what you had said before.
> I challenge you once again to come up with examples of how the bag
> interface is unimplementable.

Once again, that's not how review works. You're supposed to defend your
design by actually implementing it. It's one of the most basic
requirements of the SRFI process and of software reviews in general.

> The reference implementation implements more than one sequence, which
> have bag semantics as well, so code coverage is obviously fine.

But the interface itself is untested. Specifically, you haven't verified
that the interfaces are correctly factored between bags and their
subtypes. I spotted a defect in that area earlier; I don't remember
whether you actually addressed it. This is why it's so important to *at
least* actually implement everything.

>> Drama has nothing to do with it. I'm going by objective standards for
>> code reviews. "Major issue" means that it becomes a defect if you
>> don't fix it before release.

> What makes you think it won't be fixed before release?

Where did I say that it wouldn't be? My point is that the SRFI is not
mature. Not according to the guidelines of the SRFI process or any other
reasonable measure I can think of.

> Nevertheless, this SRFI has really only seen around 90 days of
> discussion ....

And that's already too much, especially with active discussion and
revision still going on. Those guidelines exist for a reason, to
discourage people from releasing immature, untested implementations.

> Though I am not the authority, I would like to again say that the SRFI
> process is a guideline whose rules are in place to prevent specific
> abuses such as SRFIs of indefinite extent.

The process doc and FAQ are quite clear: The guidelines are in place to
prevent finalization of an immature SRFI, and SRFI-44 meets all of the
guidelines for an immature SRFI.

>> Why would you be disappointed, when that's the documented rule?

> Because it would extend for a year the amount of time Scheme goes
> without a coherent collections API.

And why is that important (other than the fact that you have a lot
invested in it)? What good is the API without the collections
themselves? Naming standards are important, but you're seriously
overestimating their importance. Also, you're being too optimistic about
the acceptance of this SRFI, methinks -- abstract APIs without concrete
implementations have a very, very long history of failure. You're
probably better off skipping straight to the concrete collections SRFI
and hoping that its conventions catch on as a de facto standard.
Otherwise, you're far too likely to run into a combination of unexpected
defects (because the interface is untested) and Not Invented Here
(because implementors have very little reason to follow somebody else's
naming conventions unless you give them something of value besides just
a list of names).
--
Bradd W. Szonye
http://www.szonye.com/bradd