Talk:Short-circuit evaluation: Difference between revisions

(→‎Compiler optimisations?: Covered already?)
Line 48:
: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)
 
::If short-circuiting isn't covered by the language then the last sentence of the task description should hold: ''"If the language does not have short-circuit evaluation, this might be achieved with nested if statements."'' If short-circuiting is covered by the language then a compiler is either wrong or any optimisations must preserve short-circuit operations.
::--[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 15:24, 29 April 2015 (UTC)
Anonymous user