2018-06-27 15:43 GMT+02:00 N.M. Maclaren <n...@cam.ac.uk>: > On Jun 27 2018, Janus Weil wrote: >> >> >> It is very unfortunate, and it means that the Fortran standard simply >> does not provide a measure for "more correct" here. (My common-sense >> drop-in notion of correctness would be that an optimization is >> 'correct' as long as it can be proven to not change any results.) > > > Actually, yes, it does. Fortran 2008 7.1.4p2, 7.1.5.2.4p2, 7.1.5.3.2p1, > 7.1.5.4.2p1, 7.1.5.5.2p1 and 7.1.6.3p1/2.
I'm not completely sure what you deduce from all these quoted paragraphs, but applied to the cases we're discussing here, e.g. A = .false. .and. my_boldly_impure_function() I read them as saying that a compiler does not have to invoke the function if it doesn't feel like it, but with no definite obligation to remove the call either. Do you agree? > The problem is that the Fortran > standard has never resolved the inconsistency that OTHER side-effects in > functions are not explicitly forbidden Exactly. > it's one of the few places in > Fortran where there are conforming constructs that do not have specified > semantics or at least a clearly specified intention. And I really wonder why one would do such a thing. Like, ever. I'm curious: Are there actually other such cases in Fortran that you're aware of? > Many, many people have tried to sort that out, and all have failed dismally. > I regret that the proposal to deprecate impure functions did not succeed, > because at least that would have made one sane direction clear. I don't know. Why do so many people in the Fortran community have such a big problem with functions? Ok, they haven't been around in 77, but if you even bother to introduce them, why do it so half-heartedly and not just embrace them in their full beauty? What is so complicated about putting a statement into the Fortran standard that says: "Ok, if this function has side effects, we definitely must evaluate it, otherwise we lose the side effects. They might be important." ??? > This has been made much worse by IEEE 754 and (worse) coarray support. Like > almost all languages with threading and shared-memory, Fortran's concept of > pure is satisfactory for single-threaded code but not parallel. You need the > stronger concept, where a pure function does not depend on anything that > might change in its scope. We don't even need to start discussing these things if we can't even figure out what to do with an impure function in a simple single-threaded program. > Look on the bright side. If you thought this problem is a mess (it is), I > can assure you that most other languages get it far, far worse - often with > logically impossible or contradictory promises and requirements. I don't quite see that. Which languages are you talking about specifically? I see that C/C++ gives you a nice choice of writing A = false & my_boldly_impure_function() or A = false && my_boldly_impure_function() where the first option guarantees that your function is evaluated, while the second one allows (or even demands?) it to be optimized away. That's a much clearer situation than the Fortran mess, isn't it? My wish would be that instead of deprecating impure functions, the Fortran standard should rather introduce .ANDIF. / .ORELSE. operators. Cheers, Janus
