Bear wrote:
>> The "implementation" provided with this SRFI adds no capabilities to
>> any scheme system that drops it in and uses it ....

xxxxxx@freenetproject.org wrote:
> This is flat wrong.  It allows one to consistently interchange values
> between the standard Scheme types ....

Last I checked, R5RS already provides that. You have heard of
vector->list et al, right?

> ... and consistenly enumerate over them.  The current Scheme standard
> specifies no way to enumerate over all the composite datastructures at
> the moment.

Really? Lists and alists already use a common enumerator. It's called
"map." If you really need to deal with vectors and strings too, it's
trivial to roll your own enumerator. Your enumerator doesn't even
provide the multiple-collection capabilities of map and SRFI-1 fold --
it's actually less capable than existing facilities.

>> This SRFI attempts to use the SRFI process to change the SRFI process
>> itself.  That risks further damage to the SRFI process, which is
>> again much more important than this SRFI.  That is a major issue.

> The editor doesn't seem to think so.

Yes, that's very disappointing. That too damages the SRFI process in my
opinion -- what's the point in publishing requirements if you're not
going to follow them? Then again, maybe I misunderstood the editor's
reply; much of it was difficult for me to follow.

> I'm sorry I've let you down, but I don't believe I'm letting the
> Scheme community down.  You've certainly not raised any compelling
> flaws that prevent future efficiency.

Yes, actually he has. You're turning a blind eye to them, for some
reason. While I don't think you've been dishonest, nor do I think you've
been trolling, you don't seem to actually have the Scheme community's
best interests in mind.

> How is it that you think the current operators are inefficient?

How many times do we need to explain it to you before you get it? If
you're going to set the standard for collections, you really should
learn more about the major issues related to collections and how they
relate to generic programming.
--
Bradd W. Szonye
http://www.szonye.com/bradd