On Jun 27 2018, Janus Weil wrote:
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?
Yes.
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?
Yes. Some in the I/O area, where every language has problems, because
systems vary so much in their basic models. Some in the coarray area,
especially atomics. And a few others that I now forget where. I would
have to search my files (and memory!) to remind myself of exactly which
issues I was referring to, even in the areas that I can remember have
such issues. But see below.
Where impure functions are different is because the others are all either
in extreme cases or in areas that everybody knows are iffy. You can
avoid all of them (including the impure function ones) except a few of
the I/O ones by writing in a highly disciplined fashion - which is the
key to high RAS, and portability over long periods of time and wildly
different systems.
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?
Er, functions have been present in Fortran since 1958, and wording with
similar effects to the current wording since 1966. This is an OLD
problem :-(
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." ???
Because that would mean a complete redesign of Fortran's semantic model
of execution. It would also NOT be what a lot of people want. Inter
alia, you would have to define what a side-effect is - and my point
about IEEE 754 is very relevant here.
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?
Demands. But I can assure you that things are NOT that simple, and
C and C++ were among the languages I was referring to. I could go
into horrible detail, but this is not the place to do that. And, no,
the problems are not where you probably think they are.
I never counted them up, but my estimate was that they were at least
ten times as numerous and serious as for Fortran and, worse, they could
NOT be avoided even in very clean code. I base this on being involved
with the standards, personal experience of writing highly-portable code,
and experience of being the local expert of last resort in the languages.
Regards,
Nick Maclaren.
