hirchert@uxe.cso.uiuc.edu (09/23/88)
Misinformation and misinterpretations on the subject of side effects in FORTRAN
abound. I will attempt to throw some light on the subject. Let me point out
a couple of things up front:
1. I am member of X3J3 (the committee responsible for the FORTRAN standard) and
am a member of the particular subcommittee of X3J3 responsible for
researching and drafting official interpretations of X3.9-1978 (commonly
known as FORTRAN 77). Thus, you might consider me an "expert" on the
subject of what the standard does and does not allow.
2. What I am about to present comes from an official interpretation adopted
several years ago. Unfortunately, I have neither that interpretation nor
my copy of the standard in the office in which I am writing this note, so
I cannot cite chapter and verse in this note. If you have doubts about the
specifics about what I am presenting, let me know and I'll track down
exact references.
I was not a member of X3J3 when FORTRAN 77 was drafted, but as best I can
determine from talking to members who were, it was not the committee's intent
to outlaw side effects totally. They did, however, wish to prevent the
possibility of side effects from interfering with optimization of expression
evaluation. Although they attempted to outlaw side effects in only specific
cases, one of those cases can be interpreted so generally as to effectively
outlaw them in all cases. Specifically,
a standard-conforming FORTRAN program may include functions which have side
effects, but the program is prohibited from referencing the results of those
side effects.
The reasoning behing this assertion follows:
1. The standard allows a processor to suppress the evaluation of a function
reference if the value of the expression in which it appears can be
determined without it. This rule was intended to cover expressions such as
X.GE.Y .AND. LOGFUN(Z)
where if X.GE.Y evaluates to be false, then the entire expression is false,
regardless of the value of the function reference LOGFUN(Z).
2. The standard also states that in cases like the one above, anything defined
by the function must be treated as undefined when the reference is complete.
(Since we can't predict portably whether or not the processor suppresses
the function reference, we don't know whether the definition took place or
the object retained its old value. "Undefined" simply means that the
standard cannot predict the value.)
3. Standard-conforming programs are prohibited from referencing undefined
values. Thus, they are prohibited from referencing the results of side
effects from function references falling under the case above.
4. Since the standard places no limit on what the processor may do to evaluate
the function without invoking the function, _all_ function references fall
under this case. (Note that this is not a question of whether any
particular processor suppresses evaluation of a function reference. Rather,
it is a question of whether there could be such a processor. With complete
knowledge of the source of the function (and some processors have that), it
should always be possible to concoct an alternative evaluation strategy.)
Note that X3J3 has adopted an official interpretation based on the above
reasoning. (I suspect that this happened long enough ago that that
interpretation is contained in Fortran Information Bulletin #1, but since
I don't have a copy handy of that either, I can't be certain.)lamaster@ames.arc.nasa.gov (Hugh LaMaster) (09/25/88)
In article <50500076@uxe.cso.uiuc.edu> hirchert@uxe.cso.uiuc.edu writes: : >Misinformation and misinterpretations on the subject of side effects in FORTRAN >abound. I will attempt to throw some light on the subject. Let me point out : > a standard-conforming FORTRAN program may include functions which have side > effects, but the program is prohibited from referencing the results of those > side effects. > > > > The random number generator is the usual example of something that produces different results depending on which call it is. If I understand the description properly, it is now prohibited to implement a random number generator as a function: it should be a subroutine. Is this correct? (I don't have a problem with it- other than all those old codes which use x=ranf(i) :-) ). -- Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
jlg@lanl.gov (Jim Giles) (09/25/88)
From article <15436@ames.arc.nasa.gov>, by lamaster@ames.arc.nasa.gov (Hugh LaMaster): > [...] > The random number generator is the usual example of something that produces > different results depending on which call it is. If I understand the > description properly, it is now prohibited to implement a random number > generator as a function: it should be a subroutine. Is this correct? > (I don't have a problem with it- other than all those old codes which use > x=ranf(i) :-) ). Functions (as a long argument in this newsgroup has just concluded) may have side effects. The problem is that they may not have side effects that effect any other value in the same statement in which they occur (in this rule, the conditional expression in an IF statement is regarded as separate from the statement that the If guards). For example: x = ranf(i) y = ranf(i) + x The above is legal. y = ranf(i) + ranf(i) This is illegal if ranf has side effects. I would argue to the Fortran 8x committee that there should be a 'side effects' flag on the EXTERNAL statement and that the RANDOM intrinsic should be a function with side effects. My comment is that if the function was explicitly flagged as a function _with_ side effects, the second example above would still be legal and the processor would be required to call twice (in left to right order). The 8x proposal introduces RANDOM as a subroutine intrinsic instead. J. Giles Los Alamos