Richard E Maine wrote:
> On Sep 22, 2004, at 4:24 PM, James Giles wrote:
>
>> Richard E Maine wrote:
>>> Ouch. I wouldn't trust it.  According to me it is invalid. And I'd bet
>>> that someday you'll run into a compiler that figures it would be a
>>> good idea to optimize the 4 add1 calls by doing it just once.
>
>> Unless ADD1 is declared PURE, that "optimization" would be a violation
>> of the standard...
...

> One note that I don't think I mentioned before in this thread. If you
> take my advice in avoiding the practice of depending on function side
> effects, then you are completely 100% safe in this regard, no matter
> who is correct about any related point. Even if I am conclusively
> determined to be wrong about everything else on this subject, even if
> compilers screw it up, following my advice on it is still safe.

Unfortunately, this is not true.  PURE functions that use
MODULE or COMMON variables are unsafe by his
interpretation, yet he does not warn you against their
use.  If we adopt Rich Maine's interpretation of this issue,
you are probably not safe using functions *at*all* under
any circumstances.  In fact, his interpretation makes any
use of expressions doubtful.  He relies on the phrase (F95,
§7.1.7.1):

   It is not necessary for a processor to evaluate all of the
   operands of an expression, or to evaluate entirely each
   operand, if the value of the expression can be determined
   otherwise.

He insists that this phrase means that functions needn't
be executed under any circumstances at all.  Note that the
statement doesn't even explicitly mention functions.  So, that
must mean that, by his interpretation, *no* part of expressions
need ever be executed!  He claims that implementations are
permitted to evaluate expressions "otherwise", not just in
those alternate ways explicitly allowed by the remainder
of §7.1.7, but in any way they feel like.

Neither as a practical matter, nor as a matter of standard
compliance do you need to worry about the issue that Maine
raises.  The Fortran standard explicitly permits functions
to have side-effects, and specifies in a fairly clear manner
under what circumstances those side-effects *might* not
occur.  Those circumstances are not universal, but occur
only when certain mathematical identities allow the optimiser
to eliminate references to parts of expressions or when
you call the same function more than once with the same
argument in the same simple statement.  To claim that
§7.1.7.1 allows anything else contradicts §2.4.3.3:

   [...] The value of a function result is determined by execution
   of the function.

This is the only place in the document that specifies the value
of a function reference.  If, after optimization, your program
still makes use of a function's value, this is the phase that
tells you how that value is produced.  It is produced by
execution, a process that unavoidably performs *all* the
semantic consequences of the function's definition, including
its side-effects.  (In fact, I would accept "performing all the
semantic consequences" of a piece of code as the appropriate
definition of the word "execution" within the standard
document.)

Maine's interpretations would invalidate (and contradict)
so many other parts of the standard that I don't see that there's
any likelyhood at all of it ever being adopted.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare