On Wed, Oct 29, 2003 at 10:06:46AM -0800, Bradd W. Szonye wrote:
>
> A programmer cannot implement a new collection type without knowing the
> details of the dispatch method. For example, suppose that I regularly
> use PLT and Scsh, and they both provide SRFI-44. I write a grab-bag
> collection and try to fit it into PLT's SRFI-44 framework. To do so, I
> need to know how PLT implemented the generic dispatcher, so that I can
> make it aware of my grab-bag. If I also want to implement grab-bag for
> Scsh, I need to figure out how *they* implemented the dispatcher. Of
> course, they aren't compatible, so I need to re-write half of my code.
>
I agree.  Thats why this is mentioned in the issues.  But thats a 'solve
once' problem for the implementer.  Its still quite useful to all the
other programmers who are using existing collections.  If you think this
SRFI is controversial, I promise a generic dispatch (probably an OO)
SRFI would be moreso.

> >> 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.
>
> > SRFI-1 fold applies only to lists.  But thanks for admiting that
> > enumeration over vectors and strings would be useful.
>
> Yes, it is useful. But you're still missing the point. Between R5RS,
> SRFI-1, SRFI-13, and a little glue code, a programmer can actually do
> *better* than he can with SRFI-44.

Yes, but not for future collections.  Programmers can do a lot of things
to get functionality of many of the existing SRFIs, plus some more, but
that doesn't make those SRFIs less valuable.  And again the main value
of this SRFI is what it creates for future collections, not so much what
it gets you now.