Path: utzoo!attcan!uunet!yale!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: function side effects (was: i++, i+=1, i=i+1) Message-ID: <3821@lanl.gov> Date: 20 Sep 88 18:22:37 GMT References: <3987@h.cc.purdue.edu> Organization: Los Alamos National Laboratory Lines: 48 From article <3987@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > [...] 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? [...] No, I am going to state once again that the specific example you cited to start this discussion is not allowed to have side effects. I am prepared to say that section 6.6 outlaws all but the most trivial side effects (and the standard committee _intended_ to outlaw _all_ of them) in the kind of statement under discussion. You are the one who keeps introducing into the discussion things which weren't relevant to the original issue. If you want to talk about side effects in general - fine. Read section 1.4 of the standard document. Even if side effects _were_ completely outlawed, section 1.4 permits a standard conforming compiler to provide them as an extension. So, I have no problem with side effects anywhere except where they conflict with explicit prohibitions of the standard - I never have. > A(INVERT(I)) = A(INVERT(I)) + 1 I have talked to members of the Fortran standards committee. It is intended that the following optimization of the above statement be permissible: TEMP = INVERT(I) A(TEMP) = A(TEMP) + 1 This is intended to have exactly the same meaning as the line above. It is always possible that you have come across a type of side effect which the committee forgot to outlaw when considering this issue. In that event, I would bet that the committee would agree that the optimization given here is still valid. (After all, what leads you to believe that a function is called twice just because its name appears twice in a statement? The standard doesn't _require_ that, you know. The only thing required by the standard is that it compute the statement correctly - the above optimization still _does_ that.) ---------------------------------------------------------- Still, you haven't addressed the REAL issue that _I'm_ interested in - should side effects be allowed where Fortran currently doesn't allow them? If so, how can the language be modified to make such an allowance without throwing out the ability to optimize expressions? This has a bearing on the original subject of this discussion - should Fortran (or any language) have those extra assignment operators? If functions aren't allowed side effects, the extra assignments are not very interesting. J. Giles Los Alamos