This page is part of the web mail archives of SRFI 113 from before July 7th, 2015. The new archives for SRFI 113 contain all messages, not just those from before July 7th, 2015.
> 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