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.
As I've already mentioned, I have some concerns about the usability and extensibility of the interfaces defined in the SRFI. I would feel more comfortable if there were some examples of the interfaces in actual use. Examples of implementing collections: grab-bag enumerates contents in random order fibonacci an infinite sequence of numbers hash-table a dictionary implemented with a hash table red-black-tree likewise, but with an ordered tree structure 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. I'd also like to see some examples of the collections in use, to show whether the interfaces are actually useful and intuitive. A good example would be a function which sorts all the elements of a bag. 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.) 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. Basically, I'm asking whether you've eaten enough of your own dogfood to know what it tastes like. If not, you may want to hold off on releasing the SRFI to know whether it's something people will actually *want* to use. -- Bradd W. Szonye http://www.szonye.com/bradd