HaloO, Adriano Rodrigues wrote:
And we may argue as well that being Bag a multiset, the set is a special case where all the elements have the same multiplicity.
Yes, that would be a subset type. The thing I had in mind was 'role Seq does Bag' and 'role Bag does Set'. And classes with the same names for creating instances.
Going from a Set to a Seq imposes some dilemma which may be though similar to how going from a list to a scalar (it is the length, a reference, what else?). The mapping of a Set to a Seq could be parameterized via an ordering sub. But there are more possibilities.
Indeed it is easier to drop information than it is to create it in the first place. Note that the order of a Seq can be random, that is not compressable to a sub that produces it. So there's no other way than storing the order. And this is exactly what a Seq does anyway. The operational advantage of Set being a supertype of Seq is that all set operations are available for Seq out of the box. Mixed operations of Seq and Set would dispatch to the Set variant. The Seq operations like hypering are naturally precluded for Sets. Many places where the return value of Hash::keys might be put would be typed as expecting a Set. And actually returning a Set would make %a.keys === %b.keys a natural idiom. Jonathan's concerns of iterating being unavailable for a Set should be unfounded because this functionality should be in Set and hence in Seq from where we know it best. There could e.g. be a role Iterateable that Set, Range, Array and Hash do. Regards, TSa. --
