Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!uwmcsd1!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Side Effects of FORTRAN Functions
Message-ID: <50500076@uxe.cso.uiuc.edu>
Date: 22 Sep 88 20:02:00 GMT
Lines: 56
Nf-ID: #N:uxe.cso.uiuc.edu:50500076:000:3521
Nf-From: uxe.cso.uiuc.edu!hirchert    Sep 22 15:02:00 1988


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.)