Perl6's ^^

Posted Feb 17, 2015 20:46 UTC (Tue) by mbunkus (subscriber, #87248)
In reply to: Perl6's ^^ by mathstuf
Parent article: Scalar typing in the PHP world

First, Perl doesn't know Booleans as a data type. Perl knows values which are truthy (or truish or whatever you want to call them – values that cause a condition to evaluate to true) and values that are falsy. But those are not types, they're whole classes of values. Similar to C, actually. Not that I think lacking a Boolean type is good or anything, but none of Perl's operators returns a Boolean because there are no Booleans.

Second, Perl 6's man page[1] doesn't even call it an »xor operator«. It calls it »infix ^^«. It's not XOR. It behaves similar to one in that its result looks similar, but that's the same as with && and ||: those two aren't bit-wise AND/OR either because they don't look at all operands either.

[1] http://doc.perl6.org/language/operators#infix_%5E%5E

Perl6's ^^

Posted Feb 17, 2015 21:00 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (7 responses)

> doesn't even call it an »xor operator«. It calls it »infix ^^«

It also calls "||" the "infix ||" operator, but that doesn't stop anyone from pronouncing it "or". I can only see confusion coming from using "^^" for this for people who haven't taken that operators document to heart (and my eyes glaze over just looking at the table of contents…which lists 24(!) levels in the precedence chain).

Perl6's ^^

Posted Feb 17, 2015 21:05 UTC (Tue) by niner (subscriber, #26151) [Link] (6 responses)

How often do you think infix ^^ will be used in real world code? And how many of these cases will be actual chained uses with more than two operands where the shortcutting property will show?

I dare say that this whole discussion is kind of moot since this operator will just not be used often enough to confuse anyone and it's there mostly for completeness. Perl 6's designers placed very high value in consistency, so having an xor-like operator that in contrast to the others would not short cut would have been confusing indeed.

Perl6's ^^

Posted Feb 17, 2015 23:23 UTC (Tue) by HelloWorld (guest, #56129) [Link] (4 responses)

I don't buy that, xor is fundamentally different from and and or. The latter are fundamentally equivalent, each can be expressed in terms of the other and negation. For xor, this is not the case and this is by no means the only difference. For example, and and or are associative while xor isn't. Making an “xor” operator short-circuit is thus not sensible in my opinion, especially as it is usually generalised to more than two arguments by having it return true iff the number of true arguments is odd.

Perl6's ^^

Posted Feb 17, 2015 23:29 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)

You forgot that Perl6' ^^ is not xor; it's only looking like it.

Perl6's ^^

Posted Feb 17, 2015 23:34 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

Which kinda makes it inconsistent, doesn't it? So my point stands.

Perl6's ^^

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

Actually, it looks as if that doesn't make it inconsistent, because Perl 6 has done away with the built-in bitwise operators. Now, &, |, and ^ produce Junctions with different properties. And Junctions, made by joining with &, return true on a test only if all items in the Junction return true for the test, Or Junctions, made by joining with |, return true if any item returns true, and One Junctions, made by joining with ^, return true if exactly one item returns true. So ^^ returning true if exactly one item is true is consistent with ^, just not with the way ^ and xor worked under earlier versions of Perl.

Perl6's ^^

Posted Feb 17, 2015 23:31 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Oops, of course xor is also associative. Sorry about that.

Perl6's ^^

Posted Feb 17, 2015 23:43 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

I dare say that this whole discussion is kind of moot since this operator will just not be used often enough to confuse anyone and it's there mostly for completeness. Perl 6's designers placed very high value in consistency, so having an xor-like operator that in contrast to the others would not short cut would have been confusing indeed.

I don't buy that argument. If it's something that's rarely used, it's that much more likely to be confusing when somebody actually does use it. That's especially true because it changes behavior from the Perl 5 xor operator, which never short circuited.

The problem as I see it is that && and similar operations are associative when you chain them, so that $a && $b && $c && $d will always give the same result as ($a && $b) && ($c && $d), which gives the same result as (($a && $b) && $c) && $d. But that's not true of ^^; $a ^^ $b ^^ $c ^^ $d is not guaranteed to give the same result as ($a ^^ $b) ^^ ($c ^^ $d) or (($a ^^ $b) ^^ $c) ^^ $d. That is not what I expect, especially after seeing xor in Perl 5.