xxxxxx@freenetproject.org wrote:
> Even if the SRFI were withdrawn, when I resubmit it for draft it would
> still contain the following major design attributes, which are
> essential to a successful collections interface.

OK.

> 1. Generic dispatch:  This is absolutely essential in order to write
> collection agnostic code.  Without this ability, you cannot write
> generic logic that acts on collections.  This is the foundation of a
> large body of library code in languages with collections.

I agree. However, I would like to see the need for "collection agnostic
code" justified. That sounds a lot like "generic meta-programming," but
SRFI-44's support for generic meta-programming is actually very weak.
(Most of the things that would support it are currently left for later
SRFIs.)

> 2. Necessary operators (as opposed to a Kitchen Sink):  This follows
> the general Scheme philosophy ....

Is that really Scheme philosophy, or is it Scheme pragmatism? A recent
c.l.s. explanation of the minimalism in R5RS claimed that it wasn't for
philosophical reasons, but simply to avoid conflicts with existing
implementations.

If that's true, then this SRFI isn't following the principles, since it
isn't a compromise between existing implementations. Indeed, it mostly
seems to ignore prior art and set off in its own direction. If your goal
really is to avoid constraining existing implementations (like R5RS
did), then you really should do more research on those implementations
and make a better effort to avoid incompatibilities.

> 3. Metaness - This is just too important in order to have a framework
> for collections interoperability.  As in [1], the real power of a
> collections framework comes not from the specific collections that are
> eventually created ....

It sounds like you're just repeating #1 here, and the same answer
applies: I would like you to justify the importance of this and explain
why SRFI-44 doesn't actually include the usual mechanisms to support
this. There's more to it than just generic dispatch.

> 4. Enumeration - A traversal mechanism is a must for collections.
> Iterators/Cursors have problems as noted previously on the list.

Sure, no problem there, but you may want to do more research in this
area before implementing. Rather than a simplistic, one-collection,
left-and-right only approach, you may want to consider the use of
collection adapters, enumeration adapters, and the possibility of
supporting bidirectional and random-access cursors.

> For this reason arguments for withdrawal citing any of the above are
> immaterial ....

Problem: You've stated these as design goals without demonstrating that
they are actually valuable (or even true, in the case of the "Scheme
philosophy" justification).

> Additionally, the SRFI process arguments are outside the scope of
> discussion.  We can continue to discuss this on the srfi-discuss list
> if you like, but its just wasting bandwidth at this point, given that
> even the editor doesn't agree that this SRFI is abusing the process in
> a harmful manner.

Could you please stop speaking for the editors? And writing in this
"Nyah, nyah, the editors said it's OK" tone? You put a spin on it here
that I didn't get from the editors' actual writings.

Also, you'd do well to take things a little less personally and to treat
your reviewers more fairly. For example, you've repeatedly challenged us
to back up our criticisms with hard examples and detailed
justifications. However, you expect us to accept your design goals as if
they were obvious and universal desires. As you can see above, I feel
that you're overestimating the importance of this proposal, and that
some of your goals may not be supportable.
--
Bradd W. Szonye
http://www.szonye.com/bradd