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

["N.M. Maclaren" <nmm1 at cam dot ac dot uk>]

On Jun 27 2018, Janne Blomqvist wrote:
> If the semantic model is unclear on whether a function with potential
> side-effects might or might not be evaluated, then IMNSHO the semantic
> model is shit, and should be fixed or replaced.

Your opinion is noted.  For all its faults, the Fortran semantic model
has proved to be much more usable, much more robust and MUCH less full
of gotchas than those of either C or C++, to name but two.  No, I don't
love it, but everything is relative.

> > It would also NOT be what a lot of people want.
>
> Huh? Who wants that? And why??

Because side-effects include not just things that control the flow of
execution, but things like diagnostics.  Fortran takes purity seriously
and does not allow I/O in pure procedures.  It could be allowed, but
doing that would need a major change to its I/O model!

There is also code like 'X > Y .AND. SQRT(X) > Z'.  Do you REALLY want
SQRT called just to set the inexact flag, especially if the program
isn't testing it?

Not to say code like 'RANDOM() < 0.5 .and. pure_function(RANDOM()) > 1.0',
which is common in functions that generate some statistical distributions,
and in some open code that used random numbers.

> >   Inter
> > alia, you would have to define what a side-effect is - and my point
> > about IEEE 754 is very relevant here.
>
> AFAIU most languages that take purity seriously, including in particular
> Haskell, explicitly consider the IEEE exceptions outside the purity model.
> Similarly, evaluating a pure expression might cause you to run out of
> memory and the program is killed, which is most definitely a side-effect
> but not one that is taken into account in the Haskell concept of purity.
>
> I could certainly live with such compromises on purity, and I don't think
> those examples are a good excuse to do nothing.

Fortran is similar, though not the same as Haskell, in both respects.  This
is a different issue, does NOT apply to Fortran PURE procedures, and is
partly for backwards compatibility.  Tightening the rules significantly
would break many existing programs; loosening them significantly would have
a serious impact on performance.  Languages that do not have to (or can't
be bothered to) to take backwards compatibility seriously find it easier
to change things.


Regards,
Nick Maclaren.