The cancellation behavior makes no sense to me. I expect ?one(0, 1, 2, 2) to return false. That happens whether or not it collapses the 2's to one 2, but not if it ignores/cancels them.
The question is, what should ?one(0, 1, 1) return? I think it's pretty clearly false, which implies that junctions created by one() should not collapse duplicates. So we have a demonstrated desire for baglike junctions; I haven't seen a compelling need for setlike ones, but I could easily be missing something there. IOW, I tentatively agree with the proposal to just make all junctions baglike. On 11/14/08, Mark Biggar <[EMAIL PROTECTED]> wrote: > Darren Duncan wrote: >> Larry Wall wrote: >>> It seems simpler to say that one() produces bags rather than sets. >> >> If we don't make other modifications to the language then this would >> mean that a Junction is defined over a union type, "Set|Bag with >> additional behaviors", depending on what operator constructed it. >> >> Now maybe that's fine. >> >> Or alternately, why not just redefine a Junction for consistency to say >> it is a "Bag with additional behaviors" rather than a "Set with >> additional behaviors"? Would doing this break anything? Do any intended >> uses of a Junction specifically versus a plain Set|Bag involve asking >> how many instances of a value there are, or asking how many distinct >> values or value instances are in the Junction? Aside from the 3 >> answers: exactly none, exactly one, one or more? > > The meaning of any() and all() do not change if the collection is > allowed to be a Bag instead of a Set. > There are two reasonable meanings for one(), either duplicates collapse > done to single members of the collection or duplicates cancel (or are > ignored, same thing). The later interpretation would mean that > one(1,2,3,3) is the same as one(1,2), but constants aren't the > interesting case, one(@a) is. I suppose we could define a > :uniq(true|false) adverb to modify the meaning of one() so we could > have both interpretations. > > Mark Biggar > > -- Sent from Gmail for mobile | mobile.google.com Mark J. Reed <[EMAIL PROTECTED]>
