On Wed, Dec 4, 2013 at 1:37 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

Here are the outstanding issues of SRFI 13:

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 strong typing with unique objects is better here.

They are less ambiguous, more efficient for many of the

utilities, and as you say can be used to access the other

members of the enum-set.

Notably in enum-value=? etc. we can omit the enum-type

argument altogether and catch type mismatches at the

same time.

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.

Just comparators.

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?

A common pattern I use in Chibi for data structures is to

have a base library with just the type predicate and -contains?

utility, and constructors go in a separate library. Thus

other libraries could provide APIs that allow sets as arguments

for convenience, without themselves incurring any real load

overhead.

So you might have

(srfi 113 base) ; set? and set-contains?

(srfi 113) ; base + everything but enums

(srfi 113 enums) ; enums feel like they should be separate

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.

set-fold is sufficient. Cursors are awkward, and if you really

need them you can also define them on top of set-fold with

continuations.

Alex