[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open issues for SRFI 113

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.

On Wed, Dec 4, 2013 at 1:37 PM, John Cowan <cowan@xxxxxxxxxxxxxxxx> 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

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

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