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



    > From: scgmille@xxxxxxxxxxxxxxxxxx

    > 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