Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 20:35 UTC)
Re: Reasons for withdrawal Tom Lord (28 Oct 2003 21:24 UTC)
RE: Reasons for withdrawal Anton van Straaten (28 Oct 2003 22:05 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 02:50 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:19 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:38 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:36 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:32 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 22:56 UTC)
Re: Reasons for withdrawal Taylor Campbell (28 Oct 2003 23:06 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 23:28 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 23:42 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 00:13 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 01:00 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:41 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:03 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:54 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 06:40 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 06:44 UTC)
RE: Reasons for withdrawal Anton van Straaten (29 Oct 2003 07:31 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 07:34 UTC)
Re: Reasons for withdrawal Thien-Thi Nguyen (29 Oct 2003 14:08 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 21:28 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (28 Oct 2003 22:02 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (28 Oct 2003 22:22 UTC)
Re: Reasons for withdrawal Jim White (28 Oct 2003 22:15 UTC)
Re: Reasons for withdrawal Shiro Kawai (29 Oct 2003 01:25 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:44 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 04:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 04:53 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:10 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 05:17 UTC)
Re: Reasons for withdrawal Bradd W. Szonye (29 Oct 2003 05:31 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 01:49 UTC)
API conflicts (Was: Re: Reasons for withdrawal) Shiro Kawai (29 Oct 2003 05:48 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 06:03 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 17:40 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Bradd W. Szonye (29 Oct 2003 06:03 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) scgmille@xxxxxx (29 Oct 2003 14:19 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 22:25 UTC)
Re: API conflicts scgmille@xxxxxx (29 Oct 2003 22:41 UTC)
Re: API conflicts Taylor Campbell (29 Oct 2003 23:58 UTC)
Re: API conflicts (Was: Re: Reasons for withdrawal) Taylor Campbell (29 Oct 2003 21:40 UTC)
A possible solution? bear (29 Oct 2003 22:59 UTC)
RE: A possible solution? Anton van Straaten (30 Oct 2003 07:40 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 10:07 UTC)
RE: A possible solution? bear (30 Oct 2003 15:13 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:20 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:27 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 15:39 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 15:43 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 16:11 UTC)
Re: A possible solution? bear (30 Oct 2003 17:02 UTC)
Re: A possible solution? Tom Lord (30 Oct 2003 19:58 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 20:15 UTC)
Re: A possible solution? bear (30 Oct 2003 20:53 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:07 UTC)
Re: A possible solution? Taylor Campbell (30 Oct 2003 21:08 UTC)
Re: A possible solution? Bradd W. Szonye (30 Oct 2003 21:11 UTC)
Re: A possible solution? scgmille@xxxxxx (30 Oct 2003 21:17 UTC)
Re: A possible solution? bear (30 Oct 2003 23:11 UTC)
Re: A possible solution? Alex Shinn (31 Oct 2003 03:03 UTC)
Re: API conflicts Shiro Kawai (29 Oct 2003 23:19 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 00:26 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 05:32 UTC)
Re: API conflicts bear (30 Oct 2003 06:22 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 06:23 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 13:54 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:01 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:16 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 14:29 UTC)
Re: API conflicts scgmille@xxxxxx (30 Oct 2003 14:58 UTC)
Re: API conflicts Bradd W. Szonye (30 Oct 2003 15:22 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 01:50 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 03:06 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:18 UTC)
Re: Reasons for withdrawal Tom Lord (29 Oct 2003 03:29 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 03:37 UTC)
Re: Reasons for withdrawal Alex Shinn (29 Oct 2003 06:16 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (29 Oct 2003 14:25 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 02:19 UTC)
Re: Reasons for withdrawal scgmille@xxxxxx (30 Oct 2003 04:42 UTC)
Re: Reasons for withdrawal Alex Shinn (30 Oct 2003 06:22 UTC)

Re: Reasons for withdrawal Tom Lord 28 Oct 2003 21:36 UTC

    > From: xxxxxx@freenetproject.org

    > Gentleman.

    > In an attempt to break this circular flame war, please state
    > your=20 objections in a point by point matter, citing evidence.
    > Most arguments=20 are now too emotional to be valid reasons to
    > withdraw the SRFI.  If you=20 can successfully argue otherwise
    > with rationales that are objective, I=20 will consider it.

I suggest a different approach.   You should adopt an attitude of
_trust_.

By withdrawing, you gain the time to carefully review all of the
arguments already presented for withdrawal.

There have been several such arguments for withdrawal, _uncontested_
except by you, at this point.

I think the conclusion you should draw from that is not "Oh, these
guys are full of it and full of emotion -- I should only believe them
if they summarize their arguments `point by point [...] citing
evidence'.

Instead, I think the conclusion you should draw is that perhaps you
don't know as much as you think you know and that activating the
withdrawal procedure gives you freedom to consider that issue clearly.

I briefly toyed with restating my arguments for withdrawal "point by
point" but, you know, I think I stated them pretty clearly in the
first place.

Assuming that you are not a troll out to (pointlessly) scawl his name
on the srfi web site --- if nothing else, withdrawal at this point is
the politically wise move: _even_if_ (which I do not believe) your
srfi is fundamentally sound.

If you want a specific criticism, here is one of the very, very many
that are possible:

    procedure: *-get-left * [absence-thunk]=> value

      Returns a value from the given collection. For an arbitrary
      collection, it is unspecified which of its values is
      returned. More specific collection types may have more rigorous
      requirements. If the collection is empty, absence-thunk is
      invoked if present and its value returned, otherwise #f is
      returned.

    procedure: *-get-right * [absence-thunk] => value

      Returns an unspecified value from the given collection. If the
      collection is empty, absence-thunk is invoked if present and its
      value returned, otherwise #f is returned.

Um.... given those specifications, which appear to be effectively
identical, why would a client of this (meta-)interface ever use one of
these procedures in preference to the other?   Therefore why does the
interface need both?

The need for revision here is very far beyond what is reasonable for a
(respectable) srfi progressing to archival.   But, hey, it's your name
on the thing (we presume).

-t