On Tue, Oct 28, 2003 at 01:28:11PM -0800, Bradd W. Szonye wrote:
> xxxxxx@freenetproject.org wrote:
> > In an attempt to break this circular flame war, please state your
> > objections in a point by point matter, citing evidence.
>
> 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.

Additionally you must state what these major issues are, if they are not
the ones below.  Otherwise this is a redundant point.

>
> 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.

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

The rest of your argument is based on your feeling that implementations
aren't possible of some bags.  Be reasonable and cast that aside for now
since its subjective.

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

I have admitted to weaknesses in equivalence, which have been fixed, and
in the unsuitability for dictionaries with one-to-many value mappings,
as below:

>
> 4. The SRFI still lacks important primitives operations. Evidence: There
>    is no GET-ANY procedure to retrieve all dictionary elements that
>    match a given domain value. GET-ANY is necessary for dictionaries
>    with duplicate keys. It is both implementable and meaningful for all
>    dictionaries, even those with unique keys.

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

>
> 5. The SRFI does not document its relationship with other standards and
>    SRFIs. Specifically, it does not address potential incompatibilities.
>    The SRFI process requires this documentation. Evidence: SRFI Process
>    Document.

I agree.  This is also a minor issue which is easily solved.  If you
feel there are damning incompatibilities, please state them.

>
> 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.
There is no evidence that the operators that do exist have efficiency
problems.

>
> 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.  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.  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.

>
> 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.  Your objection is that the implementation doesn't implement what
you want implemented.  Lets leave this discussion out of it.

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.

	Scott