Re: [patch, fortran] Handling of .and. and .or. expressions

["N.M. Maclaren" <nmm1 at cam dot ac dot 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.  The problem is that the Fortran
standard has never resolved the inconsistency that OTHER side-effects in
functions are not explicitly forbidden - 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.

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.

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.

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.


Regards,
Nick Maclaren.