On Sat, 25 Oct 2003 xxxxxx@freenetproject.org wrote:

>> That second part is very important, and you can't excuse it just by
>> saying that it's a "meta-SRFI." I suspect that you'll eventually run
>> into problems with the way you've classified the collections. But I
>> don't know for sure, and neither do you, because you don't have *any*
>> implementation of a set or bag.

>We're going to have to agree to disagree at this point.  The API for
>both bags and sets are sound, and the remaining issues with dictionaries
>are all but solved.

I think he's right.  This is too abstract, too meta.  From joe code
writer's point of view it's not clear how to use these functions.
It's mathematics at it's finest, but I don't think it's a good
interface.

You criticized my dictionary design as being simplistic and having too
many functions.  Well, I designed it for the express purpose of doing
simple things simply, so "simplistic" isn't an insult.  As for its
having "too many functions," you know how it got that way?  It got
that way when I used the tree and alist and hash-table libraries I had
already built to construct real working projects (a parser, a
dictionary, and priority queue substructures).  I kept running into
patterns -- things I was doing clumsily, with repeated patterns of use
of the original simple functions -- and I implemented the higher-level
functions to express those patterns concisely.  This is for
convenience of actual use according to the patterns of use that were
developing in real projects.  This is how libraries that are easy and
convenient to use get built.

I don't think your design adequately covers the real-world gaps and
problems that people using this stuff are going to run into.  To the
extent that it covers them, it covers them at a high level of
abstraction that's going to cause people headaches when they just want
to do something simple or want to do it according to a pattern of use
you didn't think of.  Your concern for trying to provide a "uniform"
API for some things that are _FUNDAMENTALLY_ of a different nature
(infinite sequences and functions) has misled you; these things are
different things and _should_not_ have the same API.

I have been in shops where people were called upon to provide horribly
inefficient functions for the purpose of fitting a uniform API.  What
you wind up with is lots and lots of horribly bad code that uses
something in the worst possible way, simply because it can and because
someone was too stupid to worry about what was efficient.  Stupids
writing code will fall into the habit of using a favorite data
structure - say hash tables - and doing things with it using the
"generic" API that it's absolutely the wrong structure for (like
priority queues and ordered lists).

> SRFIs needn't have unanimous approval, nor are they
>gospel that must be implemented by all.  If this SRFI has problems, as
>you have stated without any supporting evidence, then may it die a
>horrible death of neglect.  This SRFI is a necessary step towards
>a standard library of usable collections, not the final word on such a
>library.  So, barring additional concrete criticism by others this SRFI
>will be finalized sooner rather than later.

As you say, it's your choice.  But people are giving you free advice
here, and I think it's good advice.  It looks to me like you are
providing unnecessarily complex and abstract means for stupids to
create horrible code slowly, at great expense, and doing so at the
expense of R5RS semantics.  I agree that this SRFI should probably be
withdrawn.

				Bear