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

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

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

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.

4. SRFI-44 clearly meets the definition of an "immature proposal."

> If you'll notice, in the last posted draft, vectors are purely mutable
> sequences, so they in no way conflict with R5RS.   This was fixed at
> the same time that ! and !! were merged.

And you're making these revisions 6 months into the draft period. Even
if you ignore summer break, that still clearly meets the definition of
an immature proposal that must be withdrawn.

> Its statements you make like this that keep me arguing so strongly
> with you.  You seem hell bent on withdrawal, making up reasons such as
> these that have already been addressed.

That's because withdrawal is the right thing to do in this situation.

>> There have been *plenty* of other exception-handling systems in other
>> languages, but that didn't excuse SRFI-34 from providing a complete
>> implementation. You two need to demonstrate that *your*
>> 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.

> 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.
Bradd W. Szonye