On Wed, Jun 24, 2009 at 10:35, John Macdonald wrote:
> Which means that short-circuiting is not right here - it must
> go through the entire list to determine whether there are zero
> true selections, find the first of exactly one true selections,
> or die if there are more than one true selections.
On Wed, Jun 24, 2009 at 11:10:39-0700, Jon Lang wrote:
> Which, I believe, is exactly how XOR short-circuiting currently works:
> it short-circuits to false if both sides are true; otherwise, it
> returns true or false as usual for XOR and continues on down the
> chain.
It's not a short-circuit unless you can avoid evaluating at least one
arguments at least some of the time.
When computing "odd parity" no short circuit is ever possible.
When computing "exactly one true" it's only possible if you have at
least 3 arguments; having found two that are true, you know the answer
is "false" without checking any others.
On Wed, 24 Jun 2009, John Macdonald wrote:
> Failing to distinguish "zero" from "more than one" makes cases where
> xor is of any utility even more rare, it would seem to me (and it's
> already quite rare).
Which points to a fairly obvious solution: "more than one" isn't just
false, it's an exception.
So infix:<^^> should return an unthrown exception if both operands are
"true". If one operand is already an unthrown exception, that exception
should be propagated, and the other operand doesn't need to be evaluated.
If one operand is true then return it; otherwise return the right-hand
operand (which should be false).
This solves both the human expectation ("Would you like wine or beer or
juice?" "Beer and juice please" "Sorry...") and the associativity
problem: (a ^^ b) ^^ (c ^^ d) == a ^^ (b ^^ (c ^^ d)).
-Martin
PS: Given that my suggested definition would always return one of the
values, could it be an L-value? Should it? Some cool new ways to
write obfuscated code: ($a ^^ $b) %= 2
