Bradd wrote:
>> I'd like to see at least two collections for each type: one
>> "ordinary" and one "interesting" collection. For example, an
>> "ordinary" bag just stores values and enumerates them in arbitrary
>> order. An "interesting" bag is something like the grab-bag.

Taylor Campbell wrote:
> This is an _abstract_ collections API.  There are some vague plans for
> a separate _concrete_ collections SRFI, but this SRFI specifically
> does _not_ define concrete collections, other than specifying some
> stuff about what collections R5RS defines.

Let me make it more clear, then: What good is an abstract collections
API unless you've verified that it's really works for developing and
using collections?

If you had created a set of concrete collections, used them in real
applications, and then factored out the interfaces into an abstract API,
that would be good. However, all you've really published is a design
spec for a real collections system, one that may or may not be usable by
implementors. You haven't published an actual *implementation*.

I'm going to repeat my request that you withdraw this thing, until you
establish that you have some real experience with the implementation.

>> Basically, I'm worried by the lack of a usability design goal
>> (indeed, I've seen just the opposite), and I've seen too may examples
>> of incompatible definitions. While redefining the original
>> "vector-set!" may work well on the Scheme implementation you're
>> using, it would work horribly on PLT Scheme. (SRFI-44 is not alone
>> there. SRFI-1 has a few interfaces which just don't work on PLT.)

> This is _not_ a problem of the SRFI.  This is a problem of the fact
> that people sort these things into separate libraries in manners that
> don't work.

People have sorted these things in ways that *do* work for programmers
who want optional features, who need to deal with real issues like
portability and compatibility between different code bases. You two can
continue to brush off this issue as if it weren't important, but then
you'll end up with another SRFI-0, something that's essentially
unimplementable on a wide variety of systems, because implementing it
would sacrifice other goals that are more importnat.

>> I find it unacceptable to excuse those issues with claims like, "It's
>> just a SRFI. Implementors don't need to use it," and "If programmers
>> use it wrong, they deserve what they get," and "Prior art isn't
>> important." That's a great way to develop something that *won't* get
>> used.

> You're saying this under the false presumption that this SRFI is a
> library SRFI like SRFIs 1, 13, 43, et cetera.  This is _NOT_ any sort
> of 'library,' however.

Part of it is, or do you not expect people to actually provide the
interfaces for primitive containers? And any collections created to the
spell *will* be library code, so they must play well in that
environment. I don't know what your background is, or what Scott's
background is, but the major Scheme implementors are *not* going to give
up their existing module systems, and they're *not* going to implement
SRFIs that break R5RS compatibility unless they can do it as a module.

> This is an _abstract_meta-SRFI_ designed to pave the way for future
> _concrete_ SRFIs.

And I strongly encourage you to do it the other way around, to factor
the collections interface out of working code, rather than releasing a
design doc as a SRFI. Remember, it's a Scheme Request for
IMPLEMENTATION. Where is the implementation?
--
Bradd W. Szonye
http://www.szonye.com/bradd