This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
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