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.
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.