At 6:53 PM +0100 12/1/06, TSa wrote:
HaloO Larry,
you wrote:
I think a consequence of this view is that (x) ops are all key-based set
ops unless you explicitly make sure both sides are bags. But it's still
early enough in the morning that I've not thought this through entirely...
I understand that you want first of all 'KeyHash does Hash' and then
we have three special key handling subtypes of Hash. They differ only
in the value type. With Bit <: UInt <: Any and covariant container
typing this yields KeySet <: KeyBag <: KeyHash <: Hash. And I still
opt for Seq/List/Array entering the picture as subtypes of KeyBag
because we loose no information then.
The question is now how the mixed value case Bit and UInt from
the respective KeySet and KeyBag types are handled. I think we
should promote the Bit to an Uint and go for Bag operations. Note
that Bag operations yield set semantics when fed with set data.
The subtyping of KeyBag to KeyHash is a bit bogus because we loose
Bag semantics in so far as the Any supertype of UInt is not a
generalized multiplicity. That is KeyHash is more like KeySet but
with arbitrary items indicating presence. Actuallly the Any type
might support the needed min/max and +/- calls but I guess this is
not what a user of a KeyHash would expect when she uses it as argument
to the (x) ops.
In the end it might be more practical to make Bag an interface
subtype of Set that adds multiplicity of items that is dropped
when mixed Set Bag (x) ops are used. This is where I started before
Darren mentioned the Set <: Bag fact.
Is that enough food for thought for later in the day?
Tsa,
I consider the current KeyHash|KeySet|KeyBag|Set|Bag etc in Synopsis
6 to be a good solution for users of sets and bags.
I do not understand the rationale to make any further changes as you
have described above.
Please clarify benefits of what you are debating to change, maybe
with use case examples.
-- Darren Duncan
