"Hal E. Fulton" wrote:

> For example, when you iterate over a set (at least, the way I was taught
> in discrete math), you don't get any fixed ordering. Two possibilities
> might be just to document this and let the user hang himself; or we might
> actually randomize the order so that it was actually different each time.

If we implement sets using balanced trees, then we can support the natural
tree orderings like in-order. These are very natural choices. But here the
ordering is on the keys, and I don't think we always have well-defined keys
unless we ask the user to provide one...

I also want to suggest that we allow multiple implementations for the same
ADT. For example, the default dictionary implementation could be red-black
trees, but programs with good temporal locality can use a dictionary based
on splay trees. This also allows us to plug in new implementation later if
needed.

> Another question is: Might there be times when it was difficult to tell
> whether an object being added was a duplicate? What kind of equality
> test do we use, considering that a set might contain completely arbitrary
> objects?

I guess it is not difficult to design it with enough flexibility so that the
user can decide what "equality" means. I would imagine that most of the time
users would want value semantics and so they will define their own equality
function to say when two objects have the same value.

Just my 2 cents.

-- 
All the best,
Maverick Woo