Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!ags
From: ags@h.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: function side effects (was: i++, i+=1, i=i+1)
Message-ID: <3987@h.cc.purdue.edu>
Date: 20 Sep 88 04:18:34 GMT
References: <3983@h.cc.purdue.edu> <3745@lanl.gov>
Reply-To: ags@h.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 85

In article <3745@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>How did your quote prove that I was wrong about side effects? I said that
>a particular example of code quoted in a previous article was not allowed
>to have function calls which contained side effects (actually I said that
>the compiler was free to assume that there were no side effects).  My quote
>from the standard _exactly_ proves what I said.  The fact that some other
>part of the standard explicitly allows a particular type of side effect
>doesn't make it legal in the particular case under consideration.

I have been discussing both the general and the special case.  So have
you, though you apparently don't want to admit it.  Here is what you said
originally:

>No, it doesn't cause the subscript to be evaluated twice.  In Fortran
>functions are not allowed to have side effects.  

And here is what you are saying now (from the very same posting in 
which you took me to task for discussing the general case):

>Side effects other than the one you found (which I admitted that I'd
>forgotten) _are_ extensions to the standard.  

Therefore you have been discussing the general case yourself, 
whether you admit it or not.  Moreover, your revised statement is 
still incorrect.  Here are two consecutive statements from section 
6.6.  The first is one you have referred to yourself, in the 
mistaken belief that it refutes something I said in my previous 
posting (more on that shortly).  At the moment I need the first 
statement to establish the context for the second, which is one 
you apparently overlooked entirely.  The statement numbers in 
square brackets are mine.  

[1] The execution of a function reference in a statement may 
not alter the value of any entity in common (8.3) that 
affects the value of any other function reference in that 
statement.  [2] However, execution of a function reference in 
the expression e of a logical IF statement (11.5) is 
permitted to affect entities in the statement st that is 
executed when the value of the expression e is true.

In statement [2] we find a second type of side effect that is 
explicitly allowed by the standard.  What's next?  Do you intend 
to change your statement again to say that all side effects except 
the TWO cases which I have cited are forbidden?  I am prepared to 
argue that even that statement is incorrect, but right now I want 
to turn my attention to your charge that I have been ignoring the 
special case which began this discussion.

You have correctly pointed out that because of statement [1] that 
I just quoted, the function call in my example is not permitted to 
return different values if it is called twice in the same 
statement with the same argument.  In my previous posting, 
however, I described another kind of side effect that would not 
violate this prohibition.  Here is an example.

	COMMON // E
	REAL A(10)
	E = 0.0
	DO 10 I=1,10
  	  A(I) = 0.0
10	CONTINUE
	DO 20 I=1,10
	  A(INVERT(I)) = A(INVERT(I)) + 1
20	CONTINUE
	PRINT *, E
	END
	FUNCTION INVERT(N)
	COMMON // E
	E = E + 1
	INVERT = 11 - I
	END

You will notice that the function INVERT has a side effect on the 
COMMON variable E.  This does not violate statement [1], because E 
does not affect the value returned by INVERT. I will be the first 
to agree that this is lousy code.  I am even prepared to agree 
that it might be illegal, provided you can find a statement in the 
standard to support that conclusion.  I have not yet found one.  
If you can't find one either, then perhaps that points out another 
area that needs to be corrected in the next standard.  You said 
you are primarily interested in improving Fortran.  I share your 
concern.

-- 
Dave Seaman	  					
ags@j.cc.purdue.edu