TSa wrote:
Jonathan Lang wrote:
> Would (1,2,2,3,4,4) be a Seq or a Bag?
Comma constructs a Seq, of course.
The context of the question was that you provided the above as the
result of unioning two Seqs; as such, I was trying to find out whether
you meant that the union of two Seqs should be a Seq, or if that was
an unintended artifact of the way you said it.
> IMHO, the _only_ way this
> could work would be if it's a Bag: if it's a Seq, I see no way that
> one could resolve '(1,2,3) ∪ (3,1,2)'.
This is not any different from '3' + '4' resulting in numeric 7.
It is the operator that builds Bags from (1,2,3) and (3,1,2) and
then calculates the union.
IOW, you're going with the notion that Seqs should be treated like
Bags when you apply set operations to them - that is, the order of
their elements becomes irrelevant.
> Mind you, I'm still not sold on the idea of performing set operations
> on Seqs - it may be technically feasible to do so, but it strikes me
> as fundamentally unintuitive.
But you have no problem with doing numeric stuff? E.g. (1,2,3) + (3,4)
actually means +(1,2,3) + +(3,4) == 3 + 2 == 5.
I didn't say that. For the record, I _do_ have a problem with saying
that '(1,2,3) + (3,4)' should be equivalent to '+(1,2,3) + +(3,4)'.
It's counter-DWIMish, and I'd rather see the compiler complain about
the former than to do the latter when that's not what I wanted. As a
general rule of thumb, I do _not_ want data types being coerced behind
my back. '3' + '4' producing 7 should be an exception to the rule,
not the basis for it; and the reason for the exception is that the
fact that '3' is supposed to mean the same as 3 is not very hard to
spot. Stating that (1,2,3) is supposed to mean the same as 3 is
considerably more murky.
> I'm still bothered by the idea that you have to wrap _every_ ASCII
> representative of a set operation in parentheses - something which is
> only necessary when you start applying the full range of set
> operations to non-Set entities. In particular, I want 'Set - Set' to
> produce the difference of the two Sets.
But that should be the numeric difference of the cardinalities of the
Sets. Plain - means numeric. It's the same thing that we don't do string
concatenation with + but have a stringish ~ for the task. Hence it works
to say 3 ~ 4 and end up with '34'.
Plain '-' means numeric when the terms are scalars - and possibly not
even then. Perl 6 allows for operator overloading, and it does so
because sometimes it makes more sense to have the same operator mean
different things depending on what it's operating on. The interplay
between Strings and Nums shouldn't be taken as indicative of how
everything should work.
> If set operations also apply to Seq, then (=) is not the same as ===.
> The former ignores the order of the terms; the latter only does so for
> Sets and Bags. In a way, this is what started the whole debate.
You are correct. This emphasizes the need for (=).
...or for allowing explicit conversion of Seqs to Bags or Sets, and
demanding that it be done before set operations are permitted.
Note that $a (-) $b is equivalent to $a (&) (!)$b, you have it as the
union. Or did you mean $a (|) (!)$b === (!)($b (-) $a)?
No, I goofed and meant A ⋂ !B when I said A ∪ !B.
Hmm, how is Bag complement defined in the first place? Is it just
complementing the set and goes for multiplicities of 1?
Conceptually, it would be going for multiplicities of Inf. Even if
you define Set complement, you probably don't want to define Bag
complement.
--
Jonathan "Dataweaver" Lang
