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

On Tue, Oct 28, 2003 at 04:59:59PM -0800, Bradd W. Szonye wrote:
> Why not submit the naming standard and the concrete collections
> simultaneously, then? Personally, I think it would be better to just
> propose the concrete collection SRFI and let it create a de facto
> standard for naming. Have you ever heard of a naming standard that
> succeeded without a concrete implementation to "sell" it?

I don't agree that simultaneous release is necessary, but I have no 
objection to such a collection being written and pointed to by SRFI-44 
(such as with a note in 44 about the concrete dictionary SRFI to 
follow).  Releasing simultaneously means SRFI-44 sits idle during that 
time even though its useful for non-dictionary collections now.

> > I see it as a tremendous loss to withdraw an SRFI which is largely
> > complete and of such utility to the Scheme community.
> Without a concrete implementation, it isn't "largely complete," and
> you're *vastly* overstating the value of naming conventions per se.
I disagree.

> > I agree with everything here except for the immaturity assertion which
> > time and time I've said is your subjective opinion.
> That's because, once again, you're ignoring the evidence and the
> objective standards used to define it. SRFI-44 is immature according to
> SRFI process guidelines. It's immature according to any reasonable
> standard.

Again, thats up to the editors to decide ultimately.  I'll happily 
withdraw if the SRFI is deemed unfit for the process.

> Is it stable? No, it's been revised recently.
> Are all major issues resolved? No, there are still some potential defects.
> Has it seen extensive use in a production environment? No.

Something as complex as collections is going to be revised more than say 
the basic format strings SRFI.  As for the last, again as Taylor has 
mentioned, the design combines the good elements of many languages.  
Those collections have seen production use.  But I've long ago decided I 
can't convince you of this.

> >>> 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.
> What features does SRFI-44 add that we don't already have? A standard
> naming convention? That's not compelling. Enumerators? They already
> exist as part of SRFI-1 and SRFI-13. Some vaguely-specified
> polymorphism? The cost isn't worth the benefit.

A standard naming convention and an enumerator *that works for 
collections* is critical for people to write generic code and to 
exchange data between datastructures.  Even if the costs were as high as 
you say, yes, that is a lot of utility.

> SRFI-44 does not have sufficient features to stand on its own as an
> implementation. It's a coding standard.

Its part both.  The coding standard is important for future collections.  
You keep refering to your job in code quality.  Its amazing that you're 
against a coherent standard for the future.

> You're joking, right? I'd much rather use SRFI-1 and actually get a rich
> set of features for dealing with lists than use SRFI-44 to get a small
> handful of primitives that I could write myself more quickly than I
> could figure out how SRFI-44 works.
I would too if I thought SRFI-44 would be all you'd ever get.  Please 
look beyond that.

> > 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.
> Where are the advancements? Quit pretending that it's more than a coding
> standard and a vague specification of polymorphism. As Tom pointed out,
> the polymorphism part is actually *disadvantage* for implementors,
> because it's underspecified and difficult to implement.
It has nothing to do with polymorphism, as has repeatedly been stated.  
And its more than a coding standard, as it provides an actual framework 
for datastructure interaction.  You need more than a naming scheme for 


Attachment: pgpRz1zQmQSIT.pgp
Description: PGP signature