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

	Scott