Am 14. Juni 2018 12:40:19 MESZ schrieb Janne Blomqvist
<blomqvist.ja...@gmail.com>:
>> >> >Either
>> >> >
>> >> >a) short-circuiting in left-to-right order
>> >> >
>> >> >or
>> >> >
>> >> >b) must evaluate all the arguments in left-to-right order
>> >> >
>> >> >My preference would be for a) as that is what most languages are
>> >doing,
>> >>
>> >> Well, C/C++ has two different kinds of operators that give you the
>> >choice
>> >> to specify whether you want short-circuiting or not.
>> >
>> >Presumably you're thinking of "&" and "|". But to be pedantic, those
>> >are
>> >bitwise operators, not non-short-circuiting boolean operators
>>
>> Yes, but they work perfectly fine as logical operators on booleans,
>don't
>> they?
>>
>>
>> >There are however situations where
>> >they are not equivalent to hypothetical non-short-circuiting boolean
>> >operators!
>>
>> Could you give a simple example of such a case?
>>
>
>With the usual representation of integers, for A=1, B=2, both A and B
>by
>themselves will evaluate as true, A&&B will evaluate to true, but A&B
>will
>evaluate to false.
Yes, sure, with integers you can play such tricks. But as long as you handle
only boolean values (in Fortran: .true. and .false.), & and | are proper
non-short-circuiting boolean operators.
So, to repeat my earlier statement: C/C++ gives you the choice for boolean
expressions whether you want short-circuiting or not. No ambiguities, no
confusion, no compiler-dependent code.
In Fortran, it still feels like functions as such are second-class citizens.
People seriously advise against using them. Doesn't really help the
attractivity of the language.
>>>but
>> >> >even b) would be better than leaving it undefined.
>> >>
>> >> Agreed.
>> >>
>> >> In my opinion the best strategy for gfortran in the current
>situation
>> >> would be to apply short-circuiting whenever it can be proven that
>it
>> >has no
>> >> observable consequences. E.g. a function call should not be
>optimized
>> >away
>> >> unless it is pure.
>> >
>> >Hmm, why? I don't see why always evaluating everything is less wrong
>> >than
>> >short-circuiting?
>>
>> I'm not saying it is "less wrong", but it can be less efficient. In
>that
>> sense my proposed strategy is a compromise that tries to avoid
>harmful
>> optimizations but still does optimization where it is safe.
>>
>
>If the user assumes short-circuiting, then evaluating everything is
>surprising. If the user assumes everything will be evaluated,
>short-circuiting is surprising. So whatever is done, somebody will
>think
>we're doing it wrong.
Strongly disagree here. My proposal is to apply short-circuiting only where
there are absolutely no surprises. If a user writes
my_variable = .true. and my_pure_function()
then there is no way at all for him to check if the function was called or not
(if the function is pure). And in fact it makes zero difference for the overall
program flow and all results that are produced.
To not call the function here is an absolutely valid optimization to make,
because it does not change any results, in contrast to the case of impure
functions.
IMHO it is completely insane to optimize out impure functions, just for a
little bit of speedup, but sacrificing compiler-independent results.
I really don't understand why I'm so alone here with this opinion.
Cheers,
Janus
