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
(Note the significant white space)
Or, slightly shorter:
O 51:("foobar.txt":"W"):0 E G error
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". ;-)
| [reply]
[d/l]
[select] |
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".
| [reply]
[d/l]
[select] |
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.
| [reply] |
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".
| [reply]
[d/l]
[select] |
Hello RonW,
I’m sorry, but you’re wrong about C:
C also doesn't guarantee order of evaluation
...
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.
To take the last part first: logical or can’t be transitive, because transitivity applies only to those operators which are also relations, and logical or is not a relation. But suppose it were; and let propositions p, q, r have values false, true, false, respectively. Then p OR q is true, because false OR true is true; and q OR r is also true, because true OR false is true; so, by transitivity, p OR r should also be true. But it isn’t, because false OR false is false.
Now to the important issue. The C standard does guarantee the order of evaluation for logical OR (||):
Unlike the bitwise | operator, the || operator guarantees left-to-right evaluation; if the second operand is evaluated, there is a sequence point between the evaluations of the first and second operands. If the first operand compares unequal to 0, the second operand is not evaluated.1
To the best of my knowledge, this has always been an important feature of C. This is true for logical AND (&&) as well as logical OR. For example, when dealing with pointers it is often necessary to test whether the pointer is null before attempting a dereference:
int *p;
...
if (p && *p > 10)
...
If the order of evaluation of logical AND (&&) were not guaranteed by the C standard (as it is2), the *p operation could be performed on a null pointer before the pointer is checked, causing the program to segfault. This possibility is explicitly excluded by the standard.
1The C11 Standard, document WG14 N1570 (working paper, 2011-04-12), downloaded from here. The behaviour of the logical OR operator is specified in section 6.5.14, paragraph 4.
2Ibid, section 6.5.13, paragraph 4.
| [reply]
[d/l]
[select] |
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
| [reply] |