Poor arguments against

Posted Feb 17, 2015 18:02 UTC (Tue) by mathstuf (subscriber, #69389)
In reply to: Poor arguments against by marcH
Parent article: Scalar typing in the PHP world

It[1] means that if you had:

> a ^^ b ^^ c

and a and b were truthy, c is not executed.

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

Perl6's ^^

Posted Feb 17, 2015 19:03 UTC (Tue) by marcH (subscriber, #57642) [Link] (32 responses)

Fascinating, thanks.

- So this does not run the function:

"a" ^^ "b" ^^ func_with_side_effects_returns_true()

- whereas parentheses can be used to force the function to run and have side effects like this, correct?

"a" ^^ ( "b" ^^ func_with_side_effects_returns_true() )

(I am NOT saying this would be good programming - side effects in expressions like these are typically evil anyway)

Perl6's ^^

Posted Feb 17, 2015 19:32 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (31 responses)

Short-circuiting is not just about side-effects, it's also about efficiency. Even completely side-effect-free functions can be costly to run.

Perl6's ^^

Posted Feb 17, 2015 20:04 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (27 responses)

Well, in this case, I think that the short-circuiting behavior of ^^ is *very* surprising[1]. You have three return values: "", Nil, and some truthy value. You have no idea if the 'else' branch of an if statement is because there were no truthy values or more than one without storing it in a variable (though I wouldn't be surprised to find that Perl has a built-in variable for "last control statement expression result" or even "last conditional expression result").

[1]Then again, I find many of Perl's operators surprising in and of themselves, but I digress…

Perl6's ^^

Posted Feb 17, 2015 20:11 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (26 responses)

The other logical operators (&&, ||, // and their assignment variants) are all short-circuiting, even in Perl < 6. I would have been way more surprised if ^^ wouldn't have been.

Perl6's ^^

Posted Feb 17, 2015 20:22 UTC (Tue) by dlang (guest, #313) [Link] (14 responses)

how can you possible short circuit xor? after you evaluate the first argument, you have no way of knowing what the result is going to be until you evaluate the second one.

Perl6's ^^

Posted Feb 17, 2015 20:24 UTC (Tue) by marcH (subscriber, #57642) [Link]

> how can you possible short circuit xor?

By inventing a brand new type of short-circuit without bothering giving it a new name.

Who cares about confusion - it's only Perl after all.

Perl6's ^^

Posted Feb 17, 2015 20:32 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (12 responses)

Of course you cannot short-circuit a two-operand xor. But you can short-circuit xor consisting of three or more operands. If, at any time, two of those operands are true then the result will always be false, no matter which value the other operands have.

It's been explained at least twice in this thread with links to Perl's man page giving examples for it.

Perl6's ^^

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

> If, at any time, two of those operands are true then the result will always be false, no matter which value the other operands have.

That doesn't match the diagrams on Wikipedia on xor[1]. "true xor true xor true" is "false xor true" is "true". I don't see any reasonable reduction of it such that it can be false.

[1]https://en.wikipedia.org/wiki/Xor

Perl6's ^^

Posted Feb 17, 2015 21:11 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (10 responses)

You're correct, of course, and my answer was imprecise. I should not have used the word »xor« like that because it isn't the bit-wise xor. It's infix ^^. Sorry.

Perl6's ^^

Posted Feb 17, 2015 22:20 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

Do you at least admit that there is potential for serious confusion around this operator then (whether popular or not)? IIRC, there's some law about features of programming languages always getting (ab)used.

Perl6's ^^

Posted Feb 17, 2015 23:15 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

Of course there's potential for confusion. That's always a danger with a language you're not that familiar with, especially with ones that, just like Perl, aren't that readable in the first place. For example, in PHP the ternary operator is right-associative (unlike ternary operators in any other language).

For me (and I'm really only speaking about myself here) having ^^ short-circuit is completely logical as all the other logical operators are short-circuiting as well. I find it easy to remember. Other people's brains work quite differently from my own, though, so of course they may find it a lot less logical or highly confusing.

For me »serious confusion« means a completely different set of topics in Perl. Those are also the things I dislike most about the language. For example: functions returning different results depending on context (wantarray – or the whole notion of having different contexts in the first place); the subtle but incredibly dangerous distinction between lists and arrays; all the magic and cryptically-named special variables ($_ or _ or $[ or $< or $/ or…).

Perl6's ^^

Posted Feb 18, 2015 19:41 UTC (Wed) by bronson (subscriber, #4806) [Link] (7 responses)

Now I'm really confused. You're saying "Infix ^^" is some sort of logical operation that isn't xor but everyone will be confused because '^'?

The linked page says it, "returns the first true argument if there is only one, and Nil otherwise". How is that useful? Is it common enough to be worth making it an operator? I'd google but that would obviously be futile. :)

Perl6's ^^

Posted Feb 18, 2015 19:56 UTC (Wed) by marcH (subscriber, #57642) [Link] (6 responses)

Assuming ^^ is useful, it should be part of some "list" module and given a full name and obviously not re-using the ^ symbol which is the traditional symbol for XOR.

Having the logic of this new ^^ operator somewhat related to XOR... yet different makes the re-use of the ^ symbol even worse: even more confusing, even more error-prone.

The unusual short-circuit logic which triggers only with 3 operands or more and the confusing effect of parentheses are the icing on the cake of surprises.

This looks like a futile exercise in code obfuscation; let's just stop beating a dead horse.

Perl6's ^^

Posted Feb 18, 2015 20:05 UTC (Wed) by niner (subscriber, #26151) [Link] (5 responses)

In Perl 6 ^^ is the infix operator version of the ^ junction operator.
Junction operators are: none, one (^), any (|), all (&). The infix operators behave accordingly. As such ^^'s behavior is indeed consistent with the other operators.

From Wikipedia:

List Operators

List operators construct a junction as a list:

my $options = any(1, 2, 3, 4); # Any of these is good
my $requirements = all(5, 6, 7, 8); # All or nothing
my $forbidden = none(9, 10, 11); # None of these
my $onlyone = one(12, 13, 4); # One and only one

Infix Operators

Another way to specify a junction is to use infix operators like we have already seen:

my $options = 1 | 2 | 3 | 4; # Any of these is good
my $requirements = 5 & 6 & 7 & 8; # All or nothing
my $onlyone = 12 ^ 13 ^ 4; # One and only one

Perl6's ^^

Posted Feb 18, 2015 20:19 UTC (Wed) by marcH (subscriber, #57642) [Link] (2 responses)

> Another way to specify a junction is to use infix operators...

One of the most dramatic things Open-Source changed is the fact that code is read, reviewed, reworked and read again by many more random people from many more random places with many more random backgrounds and many more education and knowledge levels. From this specific perspective Perl (and I guess PHP too - dunno it enough) are missing the open source revolution, because of this completely off the mark "There is more than one way to do it" mantra.

No Larry, computer languages should not try to emulate the fuzziness of natural languages, absolutely not. Machines are machines and humans are humans; two very different things which complement each other and don't need to copy each other.

Perl6's ^^

Posted Feb 19, 2015 7:31 UTC (Thu) by niner (subscriber, #26151) [Link] (1 responses)

Exactly! Code is a means to communicate with the next programmer and is almost incidentally executable by a computer. As you say, machines are machines and humans are humans. And humans understand human languages far better than machine code. Since the major goal is to communicate the intent of a piece of code to the next programmer that happens to read it, the fullness of a natural language can only help. And as a bonus, even the computer understands better what you're trying to achieve and thus has for example a better chance at optimizing.

Perl6's ^^

Posted Feb 19, 2015 15:25 UTC (Thu) by marcH (subscriber, #57642) [Link]

High-level abstractions and fullness are good but "There is more than one way" goes too far beyond fullness. Fullness is not the point here.

Natural languages have redundancy, semantic overlap, fuzziness, assumptions,... These have pros and cons; one (limited) purpose: expressing nuances. In pure technical communications nuances are completely unnecessary; even harmful in programming languages and any specification. For instance a natural language like English is so poorly suited to protocol specification that readers typically complain that they feel like they are reading a new, foreign language.

For driving machines (including machines that could kill), a language model to follow is not natural languages but maths: high-level, expressive, very limited redundancy and most importantly of all: unambiguous. Who wants machines to do something... "maybe"? Merely changing the vocabulary is fine since this does not change the properties, however adding assumptions and/or redundancy only brings confusion with users constantly wondering about what they are reading.

[BTW you don't seriously think that a redundant and inconsistent ^^ operator brings Perl closer to natural languages, do you?]

Perl6's ^^

Posted Feb 18, 2015 21:33 UTC (Wed) by bronson (subscriber, #4806) [Link] (1 responses)

I still don't get it. In your example, you're using ^ as an infix operator. So why does ^^ exist?

I liked Perl5, and still have some modules on CPAN, but this sort of discussion is giving me the heebie jeebies... Perl6 seems to have a number of false friends (^ and xor) and subtle nuances to learn.

Perl6's ^^

Posted Feb 19, 2015 7:27 UTC (Thu) by niner (subscriber, #26151) [Link]

^ creates a Junction: http://doc.perl6.org/type/Junction
^^ returns the first true argument if there is only one, and Nil otherwise.

Perl6's ^^

Posted Feb 17, 2015 20:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (9 responses)

It's not that it's short-circuiting, but *when* it does so that is surprising. To me, xor is a parity operator, so bailing on "more than one" is, IMO, silly. Not to mention a boolean operator not returning a boolean… Honestly, this is closer to "find me the first viable item in this list and signal if there is more than one such item"…which is *not* xor by any means. All I can tell is that Perl was already hard for me to decipher (I admit to some confirmation bias) and it doesn't look like Perl 6 is going to make it any easier.

Perl6's ^^

Posted Feb 17, 2015 20:46 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (8 responses)

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.

Perl6's ^^

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

The other logical operators (&&, ||, // and their assignment variants) are all short-circuiting, even in Perl < 6.

But xor is explicitly not short circuiting in Perl < 6, so it's quite surprising that ^^ is short circuiting in Perl == 6. To put it another way, $a && $b && $c is identical to ($a && $b) && $c, and $a || $b || $c is identical to ($a || $b) || $c. In Perl 5, $a xor $b xor $c is identical to ($a xor $b) xor $c. It violates the principle of least surprise that in Perl 6, $a ^^ $b ^^ $c behaves differently from ($a ^^ $b) ^^ $c.

Perl6's ^^

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

> Short-circuiting is not just about side-effects, it's also about efficiency. Even completely side-effect-free functions can be costly to run.

Of course. Any answer to the question I did actually ask?

Perl6's ^^

Posted Feb 17, 2015 21:37 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (1 responses)

Sorry about that. I honestly didn't know and had to compile Rakudo Star (Perl 6) first in order to give it a try. And yes, you can cause all three terms to be evaluated by using parenthesis this way:

perl6 -e 'sub a{ say "moo"; 1 }; sub b{ say "yay"; 1 }; sub c { say "stuff"; 1 }; a() ^^ (b() ^^ c())'

This will output all three strings and not just the first two.

Perl6's ^^

Posted Feb 17, 2015 22:55 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I had to compile Rakudo Star (Perl 6) first in order to give it a try.

Thanks, really appreciated.