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