Kevin Wortman scripsit:

> What happens when some of the elements passed to a set constructor are
> equal according to the comparator? Only one of the duplicate objects
> will make it into the set and the programmer may want to control which.
> In another thread I think we settled on optionally passing in a
> procedure to decide between pairs of duplicate elements. This issue
> applies to list->set, list->set!, set-map, and bag->set as well.

This is indeed an important point, which I need to think about further.

> set->list
>
> "However, repeated calls to this procedure will return a list in the
> same order until the set is mutated." Is there a motivation for this
> requirement? An implementation could conceivably want to reorder sets
> between mutations. For instance a hashtable might voluntarily shrink
> itself to cooperate with garbage collection.

An excellent point.  Removed.

> Bags
>
> Personally I would prefer the term "multiset". Has that already been
> considered?

I thought about it, as it is the more commonly used term.  But it is
not only longer, but to my mind misleading: an integer set is a set,
but a multiset is not a set.

> bag-decrement! cannot make the count of elements less than zero, right?

Right.  Added.

> It seems like the most natural equality predicate for enumeration sets
> is symbol=?, not eq?.

Right.  Fixed, with a note that in Schemes without `symbol=?`, the
implementation can fall back to `eq?`.

> The symbols passed to define-enumeration-type and make-enum-type must
> all be distinct, right?

Right.  Fixed.

> Why not include ...-intern! procedures for all types of sets?

Because intern! means the same as add! for sets with specialized types.
I suppose I could add it anyway just for completeness.

--
John Cowan  xxxxxx@ccil.org   http://ccil.org/~cowan
It's the old, old story.  Droid meets droid.  Droid becomes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale.  --Kryten, Red Dwarf