# Re: Fwd: Re: Pugs 6.2.0 released.

```Trewth Seeker wrote:
> Mark A. Biggar wrote:
> > Trewth Seeker wrote:
> > > In this case, we are dealing with '^^', a meaningless
> > > unpronounceable symbol. ```
```
Caret caret.

> > > Oh, but wait ... we also spell it 'xor',

When reading code, it's probably read as xor, but when discussing syntax
itself, I think caret caret is much more appropriate.

> > > So what does that say about proposing that xor(p1,p2,...) is true
> > > if an odd number of p[i] are true?

Not much, I think. Logical xor doesn't make sense with more than two
arguments.

> > > Clearly, xor is true iff *exactly* one of its arguments is true,

Yes, if(f?) exactly one of its TWO arguments is true.

You both use "iff". What does that mean?

> > > and of course it should return that argument (or bool::false if no
> > > argument is true).

How 'of course' is that? Lacking specification in Perl 6 documents, Perl
5's behaviour is the rule, and Perl 5 returns true or false, not the
argument that was true, or false.

I agree that it would be more useful if xor did indeed evaluate to the
single true element if there is one (and only one). Perl 5's perlop
says: "It cannot short circuit, of course." Can someone explain why it
cannot?

> > As long as you build "p1 xor p2 xor ..." out of binary xor ops that
> > is the result you get.  Computing parity is much more common that

Parity with logic xor? With bitwise xor, sure, agreed, that's the single
most useful application of the bitop. But explain to me how you get some
useful parity with xor'ed conditions?

> Sorry, but you're quite wrong here, because that literature applies to
> an associative operator, which Perl's xor is not.  ((1 xor 2) xor 3)
> == 3, while (1 xor (2 xor 3)) == 1.

Pugs agrees. (1 xor 2 xor 3) is also 3.

> and it ignores the context of the discussion in which it has been
> noted that the value of "p1 xor p2" is either p1 or p2 or
> bool::false, but not "true".

Is this official yet?

> My position is that it should either have its linguistic meaning, or
> expressions of the form "p1 xor p2 xor p3" should be disallowed, since
> there is no other natural meaning for it.  bool::true is not an
> acceptable result (unless one of p1, p2, or p3 is bool::true), and
> simply picking one or the other of p1, p2, and p3 when they are all
> true is arbitrary.  All of which was obvious if you were to follow my

Anyone using chained logic xor booleanly expecting it to get true only
if exactly one of the values is true, deserves punishment because they
should be using a one() junction instead. Which, not entirely
coincidentally, is available as &infix:<^> too, which looks
suspicously like &infix:<^^>, don't you think?

Anyone using chained logic xor for parity, ... hm, should explain to me
how they use parity as a condition, because I don't quite yet grok the
usefulness of this.

Anyone using chained logic xor in another way should be punished for not
using parens in a complex expression. (With and/or it's a minor offense,
because they're much more common.)

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
```