Re: Reasons for withdrawal

[scgmille@xxxxxxxxxxxxxxxxxx]

On Tue, Oct 28, 2003 at 03:16:36PM -0800, Bradd W. Szonye wrote:
> > Bradd W. Szonye wrote:
> >> Also, my issues include SRFI-44's failure to meet the basic
> >> requirements of a SRFI. The late date has very little to do with
> >> that. The original proposal did not address compatibility issues, and
> >> because of that, SRFI-44 was nearly finalized with an undocumented
> >> incompatibility with R5R6 Scheme. It took a risk (by not documenting
> >> compatibility issues) that would have become a major defect had a
> >> reviewer not caught it.
> 
> Taylor Campbell wrote:
> > There _is_no_incompatibility_.  R5RS _does_not_specify_ what
> > {VECTOR,STRING}-SET! return; SRFI 44 does.  That is an _extension_
> > that is _compatible_.
> 
> Will you two please set your egos aside and examine facts instead of
> making excuses? According to the original spec, SRFI-44 vector-set! was
> not an extension. It was a linear-update function, which means that
> users must rely on the return value and must not rely on side-effects to
> the input vector. With the R5RS version, users must rely on the
> side-effects and must not rely on the return value. The two are purely
> incompatible, and yet the author claimed he was ready to finalize the
> SRFI.

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

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.

> 
> 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.  It provided the mechanism, 
defering to 35 for the datastructure, which itself defered to 36 for 
concrete instances of the datastructure.

	Scott

Attachment: pgpTFq8wSdOdl.pgp
Description: PGP signature