> 8. Should we switch to unique enum objects rather than symbols?
> Symbols are all distinct from one another, and are convenient to use,
> but it's not possible to ask which enum-set a symbol belongs to, for it
> may belong to more than one.

I think symbols are best.

> 12. Should we stick to just comparators, or also allow equality
> predicates?  SRFI 114 provides comparators for `eq?`, `eqv?`, `equal?`,
> `string=?`, and `string-ci=?`, which are the Big Five.  Hash tables need
> to accept equality predicates for backward compatibility, but there is
> no real compatibility issue for sets.

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.

> 13. Should we switch to six libraries (sets, bags, integer sets,
> character sets, enum sets, and set-bag conversion), or stick with a single
> library? (This is not about dividing the SRFI itself.)  The only reason
> to do this would be to minimize namespace pollution and load space:
> if you don't need bags or charsets, you wouldn't have to have them.
> On the other hand, the whole package is only about 2 KLOC.

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.

> 14. Should we add a cursor API similar to SRFI 14's?  This would allow
> stepping through the elements in a fixed order.  It wouldn't make much
> sense for general sets or bags, but might be handy for character sets
> (via SRFI 14), integer sets, and enum sets.

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

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

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?

Kevin Wortman