ags@h.cc.purdue.edu (Dave Seaman) (09/22/88)
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
jlg@lanl.gov (Jim Giles) (09/22/88)
From article <3999@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > 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. [...] Which is what I said as well. So what is the basis of your argument. I have _never_ claimed that side effects couldn't be done in the general case. Until _you_ claimed that I had, I hadn't even _mentioned_ the general case! And as for section 1.4 of the standard - I am one of the most frequent supporters of allowing extensions. As I've repeatedly pointed out: pointers, 31 character names, bit functions, etc. are all extensions allowed in CFT77 on Crays - and _NOT_ONE_ of these feartures makes the compiler non-standard. What your original position was is hard to judge. It seems to me that your original submissions were claiming that Fortran didn't prohibit side effects in _any_ context. (After all, _you_ were the one who posted the remark that functions were allowed to change their arguments. You posted that remark in response to an article in which I claimed that the functions in A(F(I))=A(F(I))+1 couldn't. Well, they _can't_!) As for having side effects in the general case - go ahead, all you want. I do it all the time. My most common method of writing non-arithmetic subroutines is to write them as functions instead and return an error flag as the function value. So I seldom write subroutines at all, and MOST of my functions have side effects - but none of them used in the original context of this discussion do! J. Giles Los Alamos
ags@h.cc.purdue.edu (Dave Seaman) (09/22/88)
In article <3980@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >I have _never_ claimed that side effects couldn't be done in the general >case. Until _you_ claimed that I had, I hadn't even _mentioned_ the >general case! As I have pointed out several times already, and will again in a moment, you have REPEATEDLY claimed that ALL side effects are disallowed. That is how this discussion began. I have quoted the following passage before. This time I am including more of the surrounding context. In article <3659@lanl.gov> you wrote: >No, it doesn't cause the subscript to be evaluated twice. In Fortran >functions are not allowed to have side effects. The compiler will >therefore recognize the subscript expressions as common subexpressions >and will evaluate only once. Even when I quoted this before, you did not take the opportunity to correct your statement and say that you were talking only about a particular class of side effects. The reason was that you were still arguing that a particular special case that I am not allowed to mention here was illegal, and since there was nothing in the standard to support your contention, you had to make the blanket statement that all side effects are illegal. Therefore, you forced me to argue the general case. Otherwise there would have been nothing to argue. >And as for section 1.4 of the standard - I am one of the most >frequent supporters of allowing extensions. As I've repeatedly pointed >out: pointers, 31 character names, bit functions, etc. are all extensions >allowed in CFT77 on Crays - and _NOT_ONE_ of these feartures makes the >compiler non-standard. You are changing the subject again. Extensions are not mentioned in the subject of this discussion, they were not mentioned in the portion of section 1.4 that I quoted, and I have not mentioned extensions at all in this entire discussion, except in one very specific context, which was: In message <3745@lanl.gov> you wrote: >Side effects other than the one you found (which I admitted that I'd >forgotten) _are_ extensions to the standard. All I did was explain that this claim of yours was still wrong, by pointing out a second side effect that is most definitely not an extension. -- Dave Seaman ags@j.cc.purdue.edu
jlg@lanl.gov (Jim Giles) (09/23/88)
From article <4003@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > Even when I quoted this before, you did not take the opportunity to correct > your statement and say that you were talking only about a particular class > of side effects. Please point to _ANY_ statement I made about Forttran not allowing side effects for which the subject line of the article did not _explicitly_ refer to the special case in question. If you can't, you have failed to make _any_ valid point. If you don't, I will not respond to this subject again. I also have a complete history of this discussion to refer back to. J. Giles Los Alamos
ags@h.cc.purdue.edu (Dave Seaman) (09/23/88)
In article <4035@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Please point to _ANY_ statement I made about Forttran not allowing side >effects for which the subject line of the article did not _explicitly_ >refer to the special case in question. To quote Kerr Avon of "Blake's 7": How long a list would you like? Until I split the discussion into two streams (general/special case), ALL of the subject lines were either i++, i+=1, i=i+1 or function side effects (was: i++, i+=1, i=i+1) Neither of these describes the specific case we were discussing. In particular, I don't see a subscript anywhere. You made the statement that Fortran does not allow function side effects, period. I obviously could not allow that statement to stand uncontested without surrendering the entire argument. Therefore, I challenged it. Why are you surprised? In order to get anywhere, I had to make you stop talking in generalities and start talking about precisely which side effects are not allowed, according to the standard. In order to do that, I finally had to exclude the general case altogether, after which the argument terminated very quickly. -- Dave Seaman ags@j.cc.purdue.edu
jlg@lanl.gov (Jim Giles) (09/24/88)
From article <4007@h.cc.purdue.edu>, by ags@h.cc.purdue.edu (Dave Seaman): > In article <4035@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >>Please point to _ANY_ statement I made about Forttran not allowing side >>effects for which the subject line of the article did not _explicitly_ >>refer to the special case in question. > Until I split the discussion into two streams (general/special case), ALL > of the subject lines were either > i++, i+=1, i=i+1 > or function side effects (was: i++, i+=1, i=i+1) > Neither of these describes the specific case we were discussing. Both of them do since the specific case we were discussing was the replacement of i=i+1 with i+=1. You were the one who implied that: A(F(I))=A(F(I))+1 was allowed to have F modify I on the call. (In response to what I said that this function call wasn't allowed side effects, you quoted the standard which allowed functions to change their args. They can't in this case. This was the case under discussion - as explicitly placed into the subject line.) J. Giles Los Alamos
ags@h.cc.purdue.edu (Dave Seaman) (09/26/88)
In article <4100@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >Both of them do since the specific case we were discussing was the replacement >of i=i+1 with i+=1. You were the one who implied that: > A(F(I))=A(F(I))+1 >was allowed to have F modify I on the call. (In response to what I said >that this function call wasn't allowed side effects, you quoted the >standard which allowed functions to change their args. They can't >in this case. This was the case under discussion - as explicitly >placed into the subject line.) I did not intend to respond to this discussion again, but you have once again misrepresented what I said, and I must therefore once again set the record straight. I have never said or implied that the function F in the statement you give could modify its argument I. My point was always that it could modify an unrelated variable in COMMON, which could subsequently affect other parts of the program. The point of my example about dummy arguments was simply that you had made an incorrect statement. It turns out that you did not mean what you wrote, but I certainly was not aware of that at the time. I happen to know that I am not the only person who, on reading your posting, thought you actually meant that NO functions were allowed to have side effects. Claiming that the statement "Fortran functions are not allowed to have side effects" is irrelevant to the subject line is like claiming that the First Amendment to the U.S. Constitution is irrelevant to any argument over whether American citizens between the ages of 37 and 43 are permitted to discuss duck hunting in a public saloon after 4:30 on Thursday afternoons. The fact is that your statement, had it been true, would have settled the argument in your favor. That fact alone makes the statement relevant. I think we should simply agree that there was a misunderstanding between us on what you meant, which has since been cleared up, and therefore does not merit further discussion. Please refrain from misrepresenting what I said. The argument is over. -- Dave Seaman ags@j.cc.purdue.edu