Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: function side effects (was: i++, i+=1, i=i+1)
Message-ID: <3745@lanl.gov>
Date: 19 Sep 88 19:50:18 GMT
References: <3983@h.cc.purdue.edu>
Organization: Los Alamos National Laboratory
Lines: 88

From article <3983@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman):
> In article <3701@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>  [ After I quoted the standard to prove he was wrong about side effects]
> 
>>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.

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.

> You said that it was not possible to implement a random number generator
> in standard Fortran.

I didn't either.  I just pointed out that the standard has never contained
a random number generator and that maybe the constraints (in 6.6 of the
standard) were the reason why.

> You said that allowing side effects is "an extension to the standard."

Side effects other than the one you found (which I admitted that I'd
forgotten) _are_ extensions to the standard.  The standard doesn't
explicitly prohibit side effects anywhere except in section 6.6.  But
they _are_ definitly prohibited in those contexts covered in 6.6.  Some
(probably most) compilers allow functions with side effects even in
those contexts covered by section 6.6 (they allow it by simply not checking
and the rtesulting code produces bad results).

> 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 is it that I am not allowed to assume that the issue in question
is the use of multiple function calls in one statement?  That _WAS_ the
example under consideration!! 

>             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.  [...]

Read the rest of section 6.6 - these things are indeed illegal if they
effect any other part of the statement that makes the call.  That _was_
the context of this discussion wasn't it?

> Isolated special cases do not count.  It is the general rule that I am
> concerned with.

Well, here it is - the admission.  I always suspected that you had
different rules of validity for my arguments than for yours.  The issue
that started this discussion was an isolated special case of the use of 
'+=' and _you_ originated it.  Now, all _my_ arguments are supposed to 
be invalid because I constrained my discussion to that particular case.

---- End of flaming ----

Now.  The real question is not 'when and where can Fortran functions have
side effects and when can't they?'  The question should be: 'how can 
Fortran be improved so that optimization can be done without making
incorrect assumptions about function side effects?'  I still recommend
that functions should be declared to have side effects if they do.
That way the compiler would be free to apply optimizations to those
that don't have side effects _and_ the compiler could actially detect
the illegal (or unsafe) uses of functions which _do_ have side effects.
In Fortran 8x style syntax:

      side effect, external :: func1, func2

      ...

      ABC = func1(4)+func1(5)   !would be unsafe to optimize because 
                                !the order of execution might be important

      XYZ(gfunc(2))=gfunc(2)    !would be safe to optimize (call gfunc only
                                !once), gfunc has no side effects

J. Giles
Los Alamos