Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!ags From: ags@h.cc.purdue.edu (Dave Seaman) Newsgroups: comp.lang.fortran Subject: *THE GENERAL CASE* (was: function side effects) Message-ID: <3999@h.cc.purdue.edu> Date: 21 Sep 88 21:49:04 GMT References: <3987@h.cc.purdue.edu> <3821@lanl.gov> Reply-To: ags@h.cc.purdue.edu.UUCP (Dave Seaman) Organization: Purdue University Lines: 70 In article <3821@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >If you want to talk about side effects in general - fine. >Read section 1.4 of the standard document. I already have. It supports my position that side effects are allowed except where specifically prohibited. Here is the exact quote: An executable program (2.4.2) conforms to this standard if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this standard. I was already planning to use section 1.4 as the basis for building my case before you mentioned it. Precisely because of this statement, if you wish to claim that side effects are not allowed, the burden of proof is on you to show that: (1) they use forms and relationships not described in the standard, (2) they do not have an interpretation according to the standard, or (3) they are explicitly forbidden by the standard. Before I proceed, a reminder. The subject line describes the topic that I am discussing. It is your topic. You brought it up. It would never have occurred to me to discuss this if you had not pursued it. If you have something to say on a different topic, fine -- but please use an appropriate subject line. Let us consider the proposition that the standard committee _intended_ to outlaw _all_ side effects. I believe the following language would have done the trick quite nicely: 1. External functions may not modify their dummy arguments. 2. External functions may not modify variables in COMMON. 3. External functions may not contain SAVE statements. 4. External functions may not perform input/output operations. 5. External functions may not call (directly or indirectly) subroutines that do 2, 3 or 4, or which modify dummy arguments of the external function. I guess the committee _intended_ to do this, but they just forgot. The fact is that the committee explicitly contradicted points 1 and 2, and they implicitly (because of section 1.4) contradicted the rest. Michael Metcalf and John Reid are members of the committee. On page 80 of their book, "Fortran 8X Explained", they say: It is permissible to write functions that change the values of their arguments, modify values in modules, or perform input-output operations. [...] In order to assist an optimizing compiler, the standard prohibits certain side-effects. [Examples given] If Metcalf and Reid ever intended to disallow all side effects in functions, they have apparently changed their minds. The clear intent is to disallow only those side effects which might inhibit optimization. >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? That's easy. The answer is no. Those side effects that are currently not allowed have been ruled out for very good reasons. We should be doing the opposite: looking for side effects that are legal, but shouldn't be. I would mention an example, but I can't. That would be changing the subject. -- Dave Seaman ags@j.cc.purdue.edu