[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New release of SRFI 113
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.
> "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.
> Personally I would prefer the term "multiset". Has that already been
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?
> 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?
> 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 cowan@xxxxxxxx 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