> Bradd W. Szonye wrote:
>> 1. The draft period is already overdue, and there are still a few major
>>    issues to resolve. A slight delay to deal with minor issues might be
>>    OK, but extending the draft period for a re-design is not. That's
>>    what the withdraw-and-resubmit process is for. Evidence: The SRFI
>>    Process Document explains this clearly.

xxxxxx@freenetproject.org wrote:
> Additionally you must state what these major issues are, if they are
> not the ones below.  Otherwise this is a redundant point.

I've stated them enough already. If you don't remember them, you can
re-read the archive. That's what it's for.

>> 2. The reference implementation is incomplete. Evidence: There's no
>>    implementation of set, and there's no implementation of bag as a
>>    distinct type.

> I argue that no distinct implementation of bag is required since
> sequences must have all the properties of a bag.

You specify it as a distinct type but don't implement it that way.
That's an incomplete implementation.

> No implementation of set is valid.  This is an issue if the editors
> feel this makes the SRFI illegal for being too 'meta'.

No, it's not an issue for the editors. Read the SRFI process doc again.
It's the consensus of the reviewers that determines whether the
implementation is complete, not the editors.

>> 3. Dictionaries still aren't well-specified. Evidence: Author's own
>>    admission.

> I have admitted to weaknesses in equivalence, which have been fixed ....

I haven't seen the fix yet. How long will it take to review it and
possible re-implement it? Will it even get a proper review in your rush
to finalize an immature SRFI? The draft period and withdrawal process
exist for a reason.

>> 4. The SRFI still lacks important primitive operations ....

> I agree.  This however is a minor issue that can be easily fixed.

Introducing new primitives is a "minor issue"?

>> 5. The SRFI does not document its relationship with other standards
>>    and SRFIs.

> I agree.  This is also a minor issue which is easily solved.

Is it solved or not? And I would hardly call it a "minor issue" to
violate one of the few requirements of the SRFI process.

> If you feel there are damning incompatibilities, please state them.

I have already. I shouldn't have had to, though. The SRFI was supposed
to do that up-front.

>> 6. SRFI-44 does not address performance issues sufficiently, and its
>>    claim to present a sufficient "generic" interface encourages
>>    inefficient programming habits. Evidence: Conclusion based on
>>    experience and best practices in the field of re-use.

> This is subjective unless you are unwilling to agree to the premise
> that future SRFIs defining more specific operators that can only be
> applied to some or many (but not all) collections can define these
> operators.

That is insufficient, for reasons that Bear has already given.

>> 7. The SRFI is immature. Evidence: Active discussion and major changes
>>    implemented more than 90 days after the initial draft. As the SRFI
>>    Process Document states: "Active discussion or revision after 90 days
>>    normally suggests that a proposal has been revised at least 3 times
>>    and is not yet mature enough for standardization."

> This is subjective as well.  The major reason for being overdue is
> that virtually no discussion happened during the summer break.

What does summer break have to do with it? Engineers don't have a summer
break. Even for the academics, there's been 30 days before summer and 60
days after it. And you're still making revisions, and reviewers are
still discussing the proposal. The proposal *has* been revised over 3
times, and there are still major issues remaining.

This is not a mature proposal. Don't you get that?

> Either way this is an issue for the editors to decide.

>> 8. The SRFI is not an implementation at all. Evidence: The SRFI itself
>>    points out that it's a "meta-SRFI" -- it isn't even a plan for Scheme
>>    implementations, it's a design document for future SRFIs. The SRFI
>>    FAQ points out that this is the wrong venue for such documents.
>>    SRFI-44 attempts to implicitly change the SRFI process by hiding a
>>    change to that process inside a document that's nominally about
>>    something else. Bad, bad idea.

> This is by far the most subjective argument you raise.

Subjective how? SRFI-44 itself clearly states that it isn't really an
implementation. The SRFI FAQ clearly explains that this isn't the right
forum for non-implementations. You are hiding a new charter inside of a
proposal that's nominally about something else.

> It very much implements the collections it specifies.  Beyond that
> this is the call of the editors once again.  I'll also refer you to
> precedent set by SRFI-35 which both specifies conditions but defines
> none, defering that to SRFI-36.

Weren't they both proposed at the same time? The template and a concrete
implementation? You'd do well to follow that lead.

>> There is an additional risk for a "meta-SRFI": A poor implementation
>> can disrupt the SRFI process itself, as people debate whether you
>> should consider the meta-SRFI binding. Consider the discussions about
>> whether implementors should follow SRFI-1's example, and then
>> consider the additional disruption created by a SRFI that's
>> specifically intended to set an example.

> A poor implementation refers to an implementation of the SRFI that has
> flaws.

SRFI-44 has several flaws. It fails to meet the requirements of a SRFI,
and several reviewers contend that it fails to meet its own goals.

> In the interests of moving forward, I implore you to carry forward
> only with the points which are for us to decide (i.e. not the editors)
> and which aren't subjective criticisms.  That means 4, 5, and maybe 1,
> 3 are still points of contention.

What part of

    Any proposal still under active discussion and revision after 90
    days is not ready for codification. It will then be withdrawn for a
    (normal) minimum of 30 days after which it may be resubmitted.

don't you understand? Read the SRFI Process Document. Read the FAQ.
--
Bradd W. Szonye
http://www.szonye.com/bradd