Poor arguments against

Posted Feb 17, 2015 18:14 UTC (Tue) by rgmoore (✭ supporter ✭, #75)
In reply to: Poor arguments against by mathstuf
Parent article: Scalar typing in the PHP world

I'd also like to see some documentation for this. As far as I can tell (e.g. by looking at the latest version of perlop) there isn't a "^^" operator in the first place. There are "&&", "||", and "//" operators listed, but there is no "^^". OTOH, there is a low precedence "xor" operator similar to the "and", "or", and "not" operators, but the documentation specifically says:

It cannot short-circuit (of course).

My quick test shows that on the version of Perl I have installed (admittedly an older version, though with the same comment in the documentation about short circuiting), "xor" returns 1 on true and undef on false. Even if xor could somehow short circuit and return one value, it doesn't make sense for it to do so on two true values, since the return value in that case must be false and thus can't be either of the two inputs. The only case where it would make sense is to return an input is when exactly one is true and, as far as I can tell, that isn't what it does.

Poor arguments against

Posted Feb 17, 2015 18:25 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

This was perl6 (see the root of the thread). Link is in the other branch of this subthread.

Poor arguments against

Posted Feb 17, 2015 18:28 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

Now I see the source of confusion. It appears that Perl 6 is changing things compared to Perl 5. Perl 6 will have a "^^" operator (and not an "xor") that will return the value of one of its inputs on true.

The confusion for me is that it doesn't behave the way I would expect "^^" to behave when chained. It returns true if exactly one input is true, which lets it short circuit and return Nil if it finds two true values. I would expect it to return the last true value if it had an odd number of true inputs, which would make it behave the same as if you used a series of parentheses. IOW:

$a = "true";
$b = "false";
$c = "unknown";
say $a ^^ $b ^^ $c;   #prints a blank line
say ($a ^^ $b) ^^ $c; #prints "unknown"

Poor arguments against

Posted Feb 17, 2015 18:58 UTC (Tue) by marcH (subscriber, #57642) [Link] (3 responses)

> say $a ^^ $b ^^ $c; #prints a blank line
> say ($a ^^ $b) ^^ $c; #prints "unknown"

I would expect both to return nil/blank line. Did you run these?

Poor arguments against

Posted Feb 18, 2015 0:01 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

I just tested, and the first does return Nil and the second "unknown". This makes perfect sense to me, because "true" ^^ "false" returns Nil, and Nil ^^ "unknown" returns "unknown".

Poor arguments against

Posted Feb 18, 2015 0:22 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)

I thought "false" was false (why did you use it?!)

Poor arguments against

Posted Feb 18, 2015 8:30 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

In Perl 5 the following values are false in Boolean contexts: the number 0, an empty string, empty lists and arrays, undef and the string containing the single digit "0". All other values (including strings of any length > 0 no matter their content, e.g. "false") are true in Boolean contexts. The same is true in Perl 6 with Nil instead of undef.

Therefore in "true" ^^ "false" you have two trueish operands and therefore the result will be Nil.

Those strings are probably not the best and most self-explanatory when explaining Boolean concepts, though.