Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!samsung!cs.utexas.edu!yale!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ????
Message-ID: <57667@lanl.gov>
Date: 20 Jul 90 23:07:35 GMT
References: <10074@brazos.Rice.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 28

From article <10074@brazos.Rice.edu>, by saltzman@mora.rice.edu (Matthew Saltzman):
>> [...]
>>   b. However, you are not allowed to use a function with a side effect if that
>>      side effect could change the value of any other expression or
>>      subexpression in the same statement.  [...]
> [...]
> I'm sorry, but I don't see how a compiler can practically enforce such a 
> restriction.  *Any* time a variable appears as an argument to a function,
> it's a candidate for modification.  [...]

Who said anything about "compiler", "practically", or (more specifically)
"enforce"?  The Fortran standard describes a language - _not_ a compiler.
The standard only prescribes the behaviour of compliant programs. A
compiler which produces the described behaviour for all compliant
programs is a compliant implementation - regardless of what it does
with (to) non-compliant programs.

What the above rule really means is that a compliant implementation
may _assume_ that compliant programs obey the rule - and can optimize
accordingly.  The only programs that suffer from this are those which
don't comply with the standard anyway - and the standard says _nothing_
about how _those_ should behave.  ANSI C is strewn with similar stuff -
including the unpredictability of the order of side-effects in function
calls.  I suspect it is a common feature of all formally specified
procedural languages - otherwise the language wouldn't compete well
with those that _do_ permit such optimizations.

J. Giles