Re: Reasons for withdrawal

[Taylor Campbell <campbell@xxxxxxxxxxxx>]

[ Grumble.  Does _anyone_ know how to make Mail.app be smart and make
  the To: field be the mailing list instead of the sender? ]

On Tuesday, Oct 28, 2003, at 16:28 US/Eastern, Bradd W. Szonye wrote:

> scgmille@xxxxxxxxxxxxxxxxxx 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.

Notice the _large_ duration of _no_ discussion, before you barged in.
Notice how few days (seven or eight?) ago these new issues (...) were
brought up.

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

A concrete collections SRFI is an entirely different thing to tackle
altogether.  I _am_ planning on working on one soon, by the way.

> 3. Dictionaries still aren't well-specified. Evidence: Author's own
>    admission.
>
> 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.

At last!  A coherent issue!

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

What, do you want us to say that VECTOR-SET! (or STRING-SET! or
whatever) _might_ be incompatible with the current implementations of
it?  R5RS _allows_ VECTOR-SET! to return the modified vector, in fact,
because its return value is _unspecified_ by R5RS.

> 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 pretty subjective, as each party claims the evidence.

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

_You_ (and bear, et alia) were the one who came in long after the SRFI
was overdue.  Have you not noticed the, oh, _six_months_ when you
could have brought these issues up?  Saying 'I've been away from
Scheme for a long time' isn't going to help much, and it _definitely_
doesn't help bear and Tom.

Nevertheless, as the number of issues I, Scott, and Matthias can find
is very low and all of them are minor, I fail to see why a few minor
issues make a SRFI 'immature.'  Yes, you can continue to say that
there must be some implementation, but this is a silly point: most of
this SRFI is influenced from several other collection interfaces and
such, which _have_ been implemented.  Would you rather that we define
sixteen concrete collection SRFIs all with their own inconsistent
interfaces, withdraw them all to write a collection interface SRFI,
breaking any code written with them, only to rewrite them _again_ with
a new collection SRFI?

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

Please show us the correct place to submit meta-SRFIs, then.

> Please remember these two things:
>
>     Note that [incomplete implementation] is never a permanent
>     rejection, because creation of an implementation of one of the 
> other
>     types is a complete refutation of this basis for rejection.
>
> The withdrawal and resubmission process exists so that you can re-open
> the SRFI when it is mature.
>
>     Remember, even if a proposal becomes an final SRFI, the need for it
>     must be compelling enough for implementors to decide to incorporate
>     it into their systems, or it will have been a waste of time and
>     effort for everyone involved. If the quality of any SRFI is not
>     high, the likelihood of implementors adding this feature to their
>     implementation is extremely low.
>
> 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.
> --
> Bradd W. Szonye
> http://www.szonye.com/bradd