Talk:Short-circuit evaluation: Difference between revisions

Content added Content deleted
Line 83: Line 83:
:::The turbo Pascal compiler offered a B+ or B- option to choose full or short-circuit evaluation, though I don't know of any such option in a Fortran compiler. On the one hand are the simple and clear usages for ''safe & test'' and on the other are vague murmurings about unspecified potential optimisations that might involve possible parallel execution via multiple cpus or code reordering (apparently ignoring the left-to-right rule) and any amount of hand-waving. That the modern fortran standard supports the latter does not mean its words deserve respect as holy writ from on high, especially as I have often wanted the simple scheme to work and have not seen any actual gain from the fog of vapour-optimisations. Suggestions such as .OR ELSE. sound vaguely threatening! With Compaq V. Fortran, sometimes this worked and other times not, the determinant being the precise nature of the expression and operands and vagaries of compiler choices involving register allocations or whatnnot. Although conforming to the inspecificity of the standard, I don't think this is a good thing at all. I prefer definite and understandable behaviour! Which I can then take advantage of. And such reliance becomes my mistake, since the standard's choice is not mine. Fortunately, only a few usages had to be repaired, but others, especially where the compiler happens to choose short-circuitry, may lurk. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 12:21, 4 May 2015 (UTC)
:::The turbo Pascal compiler offered a B+ or B- option to choose full or short-circuit evaluation, though I don't know of any such option in a Fortran compiler. On the one hand are the simple and clear usages for ''safe & test'' and on the other are vague murmurings about unspecified potential optimisations that might involve possible parallel execution via multiple cpus or code reordering (apparently ignoring the left-to-right rule) and any amount of hand-waving. That the modern fortran standard supports the latter does not mean its words deserve respect as holy writ from on high, especially as I have often wanted the simple scheme to work and have not seen any actual gain from the fog of vapour-optimisations. Suggestions such as .OR ELSE. sound vaguely threatening! With Compaq V. Fortran, sometimes this worked and other times not, the determinant being the precise nature of the expression and operands and vagaries of compiler choices involving register allocations or whatnnot. Although conforming to the inspecificity of the standard, I don't think this is a good thing at all. I prefer definite and understandable behaviour! Which I can then take advantage of. And such reliance becomes my mistake, since the standard's choice is not mine. Fortunately, only a few usages had to be repaired, but others, especially where the compiler happens to choose short-circuitry, may lurk. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 12:21, 4 May 2015 (UTC)
::::Notice that "and then" and "or else" are part of the Ada and Pascal standards. (the extended Pascal flavor, or ISO 10206, of course not the nonstandard Borland dialects) It would arguably be nice if short-circuit was the default. Likewise, it would be nice if statements like "integer n = 0" in a function were executed at each function call. But Fortran is not C. :) [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 19:17, 4 May 2015 (UTC)
::::Notice that "and then" and "or else" are part of the Ada and Pascal standards. (the extended Pascal flavor, or ISO 10206, of course not the nonstandard Borland dialects) It would arguably be nice if short-circuit was the default. Likewise, it would be nice if statements like "integer n = 0" in a function were executed at each function call. But Fortran is not C. :) [[User:Arbautjc|Arbautjc]] ([[User talk:Arbautjc|talk]]) 19:17, 4 May 2015 (UTC)
:::::Humm. I look in the compiler "help" system, and see for example <code>COMPLEX :: cube_root = (-0.5, 0.867)</code> both declaring and initialising a variable. Whether this value would apply to only the first invocation or to every invocation presumably depends on further opportunities for declaring STATIC and AUTOMATIC and SAVE, but no matter. PL/I also has a declare and initialise protocol.

So, the options are that a language/compiler
:1) takes the expression at face value, computes both parts and then performs the '''or''' or '''and''', exactly as written.
:2) computes the first part, tests, and then evaluates the second part only if necessary.
:3) offers an option to select one or the other style, perhaps only over a limited span.
:4) supplies alternative operators: "andmaybe" and "orinstead" or other symbolism (| vs || in Octave, for example)
:5) refuses to guarantee either behaviour, talking about "any order" or even in parallel.
I know what I want... Incidentally, statement (and sub-expression) re-ordering is a popular optimisation, so even the sesquipedelian multi-statement expression may be in doubt.

I still think the lead sentence, speaking of avoiding lengthy calculation, should mention not just (''quick'' or ''slow'') but also (''safe'' and ''test'') as justification for knowing just what will happen. I don't regard avoiding an array indexing error as a side effect. If it is avoided, it doesn't happen. [[User:Dinosaur|Dinosaur]] ([[User talk:Dinosaur|talk]]) 11:28, 6 May 2015 (UTC)
Retrieved from "https://rosettacode.org/wiki/Talk:Short-circuit_evaluation"