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.
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. 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. 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. 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. 15. Should we add comparators that allow all the set types to be compared? That would allow sets of sets, bags of sets, sets of bags, etc. There is no natural ordering of sets, unfortunately; lexicographical order wouldn't make very much sense. If anyone has ideas about this, I look forward to hearing them. -- Overhead, without any fuss, the stars were going out. --Arthur C. Clarke, "The Nine Billion Names of God" John Cowan <cowan@xxxxxxxx>