On Tue, Oct 28, 2003 at 03:42:52PM -0800, Bradd W. Szonye wrote:
> xxxxxx@freenetproject.org wrote:
> > <sigh> I have not claimed the SRFI is ready for finalization, only
> > that its more constructive to discuss the remaining issues and fix
> > them than to withdraw, delaying a concrete collection for a year.
>
> 1. The SRFI process is not for preliminary ideas. If there are several
>    major issues to resolve, you're *supposed* to withdraw the proposal
>    until you've worked them out.

Round and round we go.  I don't characterize the remaining issues as
major.

>
> 2. Withdrawal is not supposed to delay anything by a year. You can
>    potentially resubmit in 30 days and finalize 60 days after that -- IF
>    you resolve all of the issues that led to withdrawal in the first
>    place.

Sorry, I was basing that off the flawed 6 month draft period.
Nevertheless, it would delay concrete collections for two draft periods
+ 30 days, assuming the second draft didn't run into a similarly
vehement opposition.  I see it as a tremendous loss to withdraw an SRFI
which is largely complete and of such utility to the Scheme community.

> 3. The desire to get a SRFI finalized and to build on it is *not* a good
>    excuse to rush into finalizing an immature proposal.
I agree with everything here except for the immaturity assertion which
time and time I've said is your subjective opinion.

> >> implementation works.
>
> > SRFI-34 didn't provide a complete package.
>
> How so? It's entirely usable on its own. It provides everything that
> primitive C++ exceptions give you, for example.

As is SRFI-44.  The Scheme collections provided are entirely usable on
their own.

> > It provided the mechanism, defering to 35 for the datastructure, which
> > itself defered to 36 for concrete instances of the datastructure.
>
> Those aren't necessary to use SRFI-34.
Nor will future collections be necessary for SRFI-44 to be useful.  To
be sure, thats not largely the point of the SRFI, but I don't believe
that conflicts with the spirit of the process, to advance portable
features beyond what is in R5RS.

	Scott