Re: Collapsing Junction states?

```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]>
```