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.

Reply via email to