Talk:Short-circuit evaluation: Difference between revisions
→Compiler optimisations?
Line 31:
: Text moved as
:: Perhaps apropos is this quote from Charles Moore's 1970 book "PROGRAMMING A PROBLEM-ORIENTED-LANGUAGE" [http://www.colorforth.com/POL.htm Moreover this attitude is reinforced by the massive trend to high-level languages and a placid acceptance of their inefficiencies: What's the use of designing a really good algorithm if the compiler's going to botch it up anyway?] --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 16:23, 28 April 2015 (UTC)
Line 38:
:::: Nowadays an issue is command line options and how they interact with subtleties of the language spec. Another issue, though, is where people have mis-read the language spec and [for example] enforce a constraint in the generated code which was meant in the specification to apply to be a constraint on the code supplied to the compiler. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 16:48, 28 April 2015 (UTC)
:Well, the Turtbo Pascal compiler offered a directive {$B+} to turn on full evaluation instead of the default of short-circuit, and appears to have diligently done so. But here is an extract from the Compaq Fortran 95 compiler...
You should not write logical expressions whose results might depend on the evaluation order of subexpressions. The compiler is free to evaluate subexpressions in any order. In the following example, either (A(I)+1.0) or B(I)*2.0 could be evaluated first:
(A(I)+1.0) .GT. B(I)*2.0
Some subexpressions might not be evaluated if the compiler can determine the result by testing other subexpressions in the logical expression. Consider the following expression:
A .AND. (F(X,Y) .GT. 2.0) .AND. B
If the compiler evaluates A first, and A is false, the compiler might determine that the expression is false and might not call the subprogram F(X,Y).
:Evidently, this compiler does what it likes in various situations, and there is no sign of any talk about short-circuit options. I recall also discussions of Algol in which an expression (A something)*(B something) might supposedly have the two parts of equal precedence evaluated "in any order". This has always irked me, as I say the order of evaluation is definite: by precedence and, left-to-right, having had experience with the importance of the order of evaluation as in something like e**3/(h*m**2) or somesuch causing exponent overflow: charge&mass of electron, Planck's constant...
:Thus, a language (or a compiler manual) may state nothing about short-circuitry, offer no option for it, and do one thing or the other in various circumstances as might be explained in a different context. So I don't think that talking about "compliant" helps, since it appears that Fortran's specifications make no statement and thus a compiler has no promise to deliver on. There is no "meta rule" that holds that all languages must declare their position on this point. In short, I think some such remark about this problem should appear in the heading - the justification for this exercise in needing clarity is not just whether or not an effortsome second function's evaluation could be avoided. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 10:50, 29 April 2015 (UTC)
| |||