Path: utzoo!attcan!uunet!husc6!purdue!i.cc.purdue.edu!h.cc.purdue.edu!ags From: ags@h.cc.purdue.edu (Dave Seaman) Newsgroups: comp.lang.fortran Subject: Re: i++, i+=1, i=i+1 Message-ID: <3983@h.cc.purdue.edu> Date: 18 Sep 88 08:45:38 GMT References: <3979@h.cc.purdue.edu> <3701@lanl.gov> Reply-To: ags@h.cc.purdue.edu.UUCP (Dave Seaman) Organization: Purdue University Lines: 78 In article <3701@lanl.gov> jlg@lanl.gov (Jim Giles) writes: [ After I quoted the standard to prove he was wrong about side effects] >May I suggest that you read the standard before making such statements? >I had forgotten the above (that is, in fact, the only side effect >allowed explicitly). But you seem to have forgotten the last paragraph >of Section 6.6.2, "Order of Evaluation of Functions": > > In a statement that contains more than one function > reference, the value provided by each function reference > must be independent of the order chosen by the processor for > evaluation of the function references. > Now, wait just a minute. I have not forgotten anything. I never said that there were NO situatations in which side effects were disallowed. I was careful to say that I had found ONE instance in which side effects are permitted by the standard. This is already enough to prove my point that side effects are not always forbidden. You, after all, were claiming right up until you read my response that there were NO situations in which side effects were allowed. You said that it was not possible to implement a random number generator in standard Fortran. You said that allowing side effects is "an extension to the standard." And now you are telling me that I am the one who needs to read the standard? Let me point out two things about the statement you quoted from the standard. If the intent was to rule out side effects altogether, then why is that first clause there? Why is the restriction so narrowly worded that it applies only when there are multiple function calls in a statement? And why does it only rule out one particular category of side effect (the ones that would affect the functions' returned values)? It does not even guarantee that it is safe to evaluate the subscript only once in my example which started this discussion. The function may increment a variable in COMMON each time it is called. This need not affect the value returned by the function, but it certainly can affect other parts of the program. Judging by your latest reply, you apparently still believe that all side effects other than the one I quoted are forbidden. I claim the standard says otherwise. I do not have the standard in front of me as I write this, but I can paraphrase some things that I read two days ago. My evidence: 1. The section on statement functions contains a restriction that is somewhat similar in spirit to the one you quoted: If a statement function calls an external function, the external function may not alter any of the statement function arguments. Again, the reason for the restriction is clear. Again, the restriction was worded as narrowly as possible. The clear implication is that whatever is not specifically prohibited in the standard is allowed (at least as far as side effects are concerned). More on this in a moment. 2. The section that spells out restrictions on external functions fails to restrict side effects in any way, as I previously noted. 3. I remember reading a statement to the effect that "whatever is allowed in external subroutines is also allowed in external functions, with the following two exceptions ...." I looked up the cited exceptions, and neither of them concerns side effects. Since side effects are permitted in subroutines, it looks very much as if they are permitted in functions as well. I will look up the paragraph number for this if you don't believe me, but you shouldn't have any trouble finding it yourself. It is obviously in the chapter that talks about external functions. In short, I claim that side effects are normally legal in Fortran functions, and I believe the burden of proof is on you to show otherwise. Isolated special cases do not count. It is the general rule that I am concerned with. -- Dave Seaman ags@j.cc.purdue.edu