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