my understanding is that or was added as an alternative to || primarily for flow control purposes in constructs such as open my $file, '<', 'somefile.txt' or die; where the high precedence of || would cause unexpected issues.

While the Perl documentation does mention flow control uses (and I am guilty of using it that way), not all programming languages guarantee the order in which terms are evaluated, or even short-cutting.

In any case, or is named for a logic operation, not a flow control operation. So, would be better if we used if (or unless) instead of or for flow control.

Update:

Another thought: Just as if (and unless) can be used as a modifier, else could be used as a modifier. That would be clear indication of intent.

Unfortunately, unlikely an else modifier would be added to Perl. The devs would likely say "Just use or"

Just as if (and unless) can be used as a modifier, else could be used as a modifier. That would be clear indication of intent.

Ahhh, the sweet smell of MUMPS:

  OPEN 51:("foobar.txt":"W"):0
  ELSE  GOTO error
[download]

(Note the significant white space)

Or, slightly shorter:

  O 51:("foobar.txt":"W"):0 E  G error
[download]

I can live with both, but open ... or die is shorter than open ... else die, and it's not that hard to understand.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

not all programming languages guarantee the order in which terms are evaluated, or even short-cutting.

Fortunately, we're talking about Perl here, not about "all programming languages", and Perl does guarantee a specific order of operations in which || is very-high-precedence, or is very-low-precedence, and shortcut evaluation is the rule.

I'm curious, though... Could you name a couple of languages in which the order of operations is not guaranteed? I don't think I've ever seen one myself and I have a hard time imagining the practical use of having an indeterminate order of operations.

Just as if (and unless) can be used as a modifier, else could be used as a modifier.

Not all programming languages allow the use of if or unless as statement modifiers, nor the use of else in that fashion. If using or for flow control is bad practice because it's not reliable in other languages, then surely the use of statement modifiers is just as bad.

That would be clear indication of intent.

As a native speaker of English, I find "open or die" to be a vastly clearer statement of intent than "open else die".

Could you name a couple of languages in which the order of operations is not guaranteed?

I can name you one: Fortran. In standard Fortran 95 the only way of enforcing an evaluation order on two or more conjoined logical expressions is by nesting them as separate IF statements.

There's a discussion on this at SO which details some other exceptions.

I'm curious, though... Could you name a couple of languages in which the order of operations is not guaranteed? I don't think I've ever seen one myself and I have a hard time imagining the practical use of having an indeterminate order of operations.

Besides FORTRAN, which hippo mentioned, C also doesn't guarantee order of evaluation

Update: Apparently, logical or (and, presumably logical and) does have its evaluation order specific in the C11 standard. (pointed out by Athanasius)

Not all programming languages allow the use of if or unless as statement modifiers, nor the use of else in that fashion. If using or for flow control is bad practice because it's not reliable in other languages, then surely the use of statement modifiers is just as bad.

There's a difference between "not reliable" and "not supported".

Proper evaluation of or doesn't require a particular order for evaluating its operands to get the correct result. This is because or is transitive. The compiler is free to evaluate the operands as is convenient. It could even turn the operand expressions into tasks that a multi-threaded CPU could execute in parallel.

Update: Correction: The proper term is "commutative", not "transitive". (thanks, Athanasius)

Statement modifiers are not transitive. They intrinsically require a particular order of evaluation. if, as a statement modifier, requires right-to-left evaluation of its operands to produce a correct result. An else modifier would require left-to-right evaluation. The compiler doesn't get to choose which order is more convenient.

While, in Perl, the intent of something or die; is reasonably clear, something or something_else; is not as clear. While it being in void context might imply intent, it could just as easily be a mistake.

something else something_else; would be unambiguous in its intent.

As a native speaker of English, I find "open or die" to be a vastly clearer statement of intent than "open else die".

The computer is not. And I would say that the "die" part of "or die" is what gives that its clarity. And while common use of English encourages left-to-right evaluation, "something_else or something" is a fully valid, English interpretation of "something or something_else".

In any case, or is named for a logic operation, not a flow control operation. So, would be better if we used if (or unless) instead of or for flow control.

This is a weak argument, because for lots of things, the documentation was added to explain the behavior, not to explain what the designer envisioned.

The http://perldoc.perl.org/perlop.html#Logical-or-and-Exclusive-Or explains or is useful for control flow purposes, thats as close to an endorsement as you can get, documented behavior that can be relied upon