Re: XOR does not work that way.

```HaloO,

Martin D Kealey wrote:
```
```Assuming you meant "^^" rather than "&&", then under my proposal, that's not
the case.
```

```
Of course! Silly me, sorry.

```
```In particular, True ^^ True evaluates to TooManyException. If that exception
is implicitly thrown, then that's what you get from the whole expression.

If not, TooManyException ^^ Anything doesn't evaluate the right operand at
all, and returns the value of the left operand.

So you'd get the same answer regardless of whether you put brackets in or
not.
```
```
I see. But I wouldn't make that an exception but ^^ returns a tristate
value instead of boolean. The third state besides True and False is
TooMany that evaluates to False in boolean context. But ^^ can react
to it as you describe. That solves the associativity problem, indeed.
Hmm, perhaps a TooFew value is nice as well. Then one can use that to
switch over the xor:

given \$x ^^ \$y ^^ \$z
{
when TooMany {...}
when TooFew {...}
when True {...}
}

A nicer set of return values would be Many, One and Zero. Numeric values
could be Many = -1, One = 1 and Zero = 0, so that they numerify nicely.
So can we write that into the spec?

Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan
```