[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reasons for withdrawal

This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.

[ 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

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

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