On Sat, Jun 1, 2013 at 9:02 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

Here is an updated issues list:

1) R6RS provides define-enumeration to help set up enum-types. Is
this worth having? Possible syntax is: (define-enumeration <type-name>
(<symbol> ...) <constructor>)

This would bind <type-name> to the enum-type, and constructor to a
curried version of make-enum-set that already knows what type to use.

I have mixed feelings about that form. It seems useful, but its type-checking syntax has always felt odd.

2) Should there be a mechanism to convert between integer sets and
integers as bitvectors, as defined in SRFI 33, SRFI 60, and R6RS?

That sounds like a great idea. Otherwise, many people will implement it independently and the results will be incompatible in unimportant ways the make it hard to share values across code.

6) Are bags really useful enough to include?

Absolutely.

7) Should bags be called multisets (msets?) instead?

The name "bag" is clear, but since enumeration sets are provided as well, and use the prefix enum-set, it makes sense to use multi-set (hyphenated) for consistency.

8) Should we switch to unique enum objects rather than symbols?

I don't see the use case for yet another type.

9) The word "set" is heavily overloaded. Should we use "gset" or
"generic-set"?

No. The meaning is clear from context.

Here are a few additional comments on the draft:

The definition of make-set says that string-ci=? must be supported. Shouldn't string=? be supported, too, then?
Why does the non-empty constructor, set, have a different name than the empty-set constructor, make-set?
Should set-find take a parameter that specifies what value to return when the searched-for element is not found? That would solve the problem with #f.
Set operations should include an operation that adds an element to a set, returning a newly allocated set, but which does not require wrapping the new element in a set that is going to be thrown away immediately. In other words, there should be a functional analog to set-add!.