HaloO, Darren Duncan wrote:
This may be a non-issue from a user's viewpoint, but as a user, I want set operations that have sets as input to return sets as output by default. Eg, unioning 2 Set that have common values should return a Set.
First of all the operations could be overloaded. Secondly the bag operations are defined in terms of min and max and therefore result in Sets remaining Sets at least in the sense of a Bag with all element multiplicities being 1.
Moreover, since set operations would be a lot more common in practice than bag operations, the set operations should be the most terse, if they both aren't equally terse.
I think the operators are the same. And with Seq a subtype of Bag they are applicable to Seqs as well. Some operations like (+) however make no sense for Sets and so they return a Bag. That is similar to using Bool values as arguments to numeric operations: True + True == 2.
I see the matter as being similar to Int vs Num. Any operation whose operands are Ints should return Ints wherever it is conceivable to do so. In particular, this means that dividing an Int by an Int should return an Int.
As a kind of compromise an Int division could return a "doubled" value with but: 5 / 4 == 1 but 1.25.
(Also, the modulus should be undefined for 2 Num.)
This could be achieved by introducing the modulus on the Int level. But I think that modulus can be easily generalized to Num. E.g. 3.2 % 2.4 == 0.8. Handling negative divisors is more of an issue. With the Euclidean definition of modulus a negative sign should not propagate into the result. E.g. 8 % -3 == 8 % 3 == 2.
Only promote an Int to a Num if one or more other operands are already Num, even if the value of that Num is a whole number.
I'm not sure that this is the intent of the current spec. I personally value adherence to the subtyping of Int and Num higher than keeping a pure Int subsystem. Regards, TSa. --
