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.
I've been intrigued by some of the soap-opera aspects of this list to which, aside from that, I haven't paid much attention. I'd like to add some comments not (much) on the threads, but on the SRFI itself. Quotations in the following (indicated by indentation) are from the SRFI. As standard Scheme lacks the ability to automatically dispatch on different function behaviors based on the types of arguments, it is difficult to devise a portable implementation of this SRFI which allows arbitrary future collections. At the risk of opening a can of worms, would it perhaps be better to: a) withdraw this SRFI to reset the clock b) devise and submit a SRFI to fix the quoted issue c) revise this proposal in light of the fix d) resubmit this SRFI ? The reference implementation in this SRFI compromises by using the portable Tiny-CLOS object system as a framework for collection-function dispatch. I think people would be quite justified to be skeptical of reference implementations that involve dragging in a bunch of code not directly related to the SRFI itself, and not not provided by other SRFIs -- especially code that aims to attack a really fundamental issue that deserves attention on its own. I'd be far more comfortable if, if Tiny-CLOS is _really_ desirable here, the pattern were: a) withdraw this SRFI to reset the clock b) devise and submit a SRFI for Tiny-CLOS c) resubmit this SRFI That's just a specific variation on the (a), (b), (c) .... pattern given previously. This SRFI's API is accommodating to purely functional and linear-updating collections by default. Some collections may be purely mutable. That is, updates are done purely through side effects within the collection. In such a collection, (eq? <input collection> (update-procedure <input collection>)) "purely mutable" is pretty close to an oxymoron where I come from. I think you mean, simply, "mutable". That an UPDATE-PROCEDURE should be expected to return it's collection is over-specification and ill-considered-specification. More commonly, in my experience, udpate procedures produce either an unspecified result or a result EQ? to the value added. The apparent intent of the introduction of "purely mutable" is to respond to a common lisp idiom in which you have some data structures which are mutable, but in which some updates might create a new "head" value for the data structure. As in: (set! my-alist (alist-set! my-alist key value)) I advise simply not being concerned with that idiom. Assert that data structures that require that idiom are not covered by this collections SRFI -- it's an icky, low-level idiom (of concern to collection implementors, not collection users). Long sections of the SRFI simply emulate the smalltalk class hierarchy with a little bit of lisp spin. This though, is the absolute topper: This SRFI behaves more as a meta-SRFI for future SRFIs to define concrete collection types. However, a reference implementation for the collections wrapper around the common Scheme types is provided in the archive srfi-44.tar.gz. It requires SRFI's 1 (list-lib), 23 (error), and the Tiny-CLOS portable object system to provide type dispatch. Brad is exactly right. That is completely unacceptable for any SRFI that you expect people to take seriously. The ideal, with a few exceptions that don't apply in this case, is that the reference implementation is something you drop into your implementation and get an at least workable version. While that may be less true of something that strikes really deep, like SRFI-34, it is certainly true of a data structures SRFI. And it's not at all obvious that a tower of collections types should include lisp idioms like lists and alists and so forth. I suspect that it should not. Overall, the SRFI has a kind of "flavor" that suggests you really wish you were programming in CLOS or Smalltalk. In that context, instead of a lame "meta-SRFI" you could really nail the topic and give us an uber-cool collections SRFI with a solid reference implementation. Instead, we're getting handwaving and vague advice and an implementation that doesn't have much value in the context of SRFI-using implementations. Look at something like SRFI-1 for an example of a data structures SRFI that both nails its problem space and provides a drop-in-and-use-it reference implementation. You ain't even close to that level of quality here. BRAD IS RIGHT. But I'll give better advice them him :-).... a) withdraw this SRFI to reset the clock b) drop down a level and think about making a SRFI for a good, portable, forsightful object system. Otherwise, I predict, this SRFI isn't going to do much good. Now, harshness aside, it's pretty apparent that you're thinking in really good ways about the issues around collections. You're on a good path here. Just please consider the advice and: a) withdraw this SRFI to reset the clock b) drop back and do more groundwork first Don't forget that the SRFI process is robust in the face of completely bogus SRFIs -- but author reputations are not. "reset the clock", -t