Kevin Wortman scripsit:

> [8] I think symbols are best.

Agreed; removed.

> [12] I think it should be comparators only. Otherwise there is an implicit
> union type of comparator-or-equality-predicate. Code that depends on
> this SRFI, or mimics it, would also need to deal with the
> comparator-or-equality-predicate type, so code handling that concern
> would be scattered all over the place. Creating a comparator is easy so
> I think it's reasonable to expect client code to do that.

I agree.  My only reservation is that hash tables will have to support
naked equality predicates for backward compatibility with SRFI 69 and
R6RS.  But I think we can allow them in that SRFI and deprecate them
instead of allowing them anywhere.  Removed.

> [13] In my use cases the time and effort that it takes programmers to find
> and import multiple fine-grained libraries is far costlier than the time
> it might take a Scheme environment to load a single coarse one, so I say
> stick with one library.

It's not so much time-to-load as namespace pollution.  The library as
currently specified introduces 238 identifiers.  Admittedly they are
named according to a fairly small number of patterns, which hopefully
will make collisions unlikely.  I'll leave things as they are.

> [14] This can be deceptively complex with mutable structures, since all the
> interactions between mutative operations and pre-existing cursors need
> to be defined precisely.

Or just say, as Java does and as I do in HashTablesCowan, that the effect
of mutating a hash table with live cursors is undefined.

> If we do go down this route I would advocate using streams (lazy
> sequences) for this purpose rather than inventing a new cursor API.

I'll hold off on anything like that for this SRFI then until we get
to streams.  Closed.

> Presently one could iterate through a set by converting it to a list and
> using established list iteration methods, admittedly with O(n) space
> overhead. Are there use cases where this would be inadequate?

Character sets in the Unicode domain are an obvious counterexample.
In Unicode 6.3, for example, (char-set->list char-set:letter) returns
a list of 89,843 characters.  Still, we could leave that functionality
just in SRFI 14.

--
Overhead, without any fuss, the stars were going out.
        --Arthur C. Clarke, "The Nine Billion Names of God"
                John Cowan <xxxxxx@ccil.org>