Functions with side effects
in [Fortran]
|
From: robin on 19 Jul 2010 20:36 Gordon Sande wrote in message <2010071909144816807-GordonSande(a)gmailcom>... >On 2010-07-19 02:42:49 -0300, Ron Shepard ><ron-shepard(a)NOSPAM.comcast.net> said: > >> In article <1jlsg86.7ybjxk14lwxdgN%nospam(a)see.signature>, >> nospam(a)see.signature (Richard Maine) wrote: >> >>> gmail-unlp <ftinetti(a)gmail.com> wrote: >>> >>>> I think bullet item 2 in 16.5.6 of F2003 does not apply since, >>>> specifically, in "If the evaluation of a function may cause a >>>> variable to become defined" the condition "the evaluation of >>>> a function may cause a variable to become defined" is false, >>>> because variable n is already defined as I understand from >>>> the standard: >>> >>> No. You misunderstand what it means to "become defined" in the standard. >>> If you give a value to a variable, that variable has become defined. It >>> does *NOT* matter whether or not it was defined before. >>> >>>> thus, n is initially defined, and in function f it is >>>> (just) given a new value for variable n. >>> >>> Giving it a value *IS* defining it. >> >> I think this is all correct, but the problem seems to be that if the >> function is *NOT* called because of some allowed optimization, then the >> previously defined value for that variable (which has not changed) >> becomes undefined. >> >> It seems to me that this is a different situation than, say, two >> variables of different types (say integer and real) being equivalenced >> to each other, and in which one variable becomes undefined when the >> other variable is defined. The bits in the memory location are >> changing, so I can see how the previously defined value becomes >> undefined (and in fact, the new bit pattern might not even correspond to >> a valid bit pattern for the other type). In the above situation, the >> bit pattern is *NOT* changed, but due to some detail of the semantics, >> it becomes technically undefined. > >In earlier versions of the Fortran standard the DO index became >undefined upon normal exit from the DO loop. Some vendors exited with >"n", others with "n+1" and others only had the index in a register so >the exit value could be anything. Indeed. The same compiler could exhibit more than one possibility -- in non-optimising mode, the value of the control variable might be returned to storage at each increment, but in optimising mode, the value might be retained in a register during the entire loop and never returned to storage. So, upon normal loop exit, no value of the control variable could be replied upon, and "undefined" simply meant not defined". Curiously, if the loop terminates prematurely (under the control of some IF statement, for example), the value of the control variable does have a reliable value, and in this case, the value of the control variable -- wherever it is, whether in register or otherwise -- is stored in the control variable and is accessible. It would have been no more difficult to store this value on normal loop exit instead of leaving the value in limbo. > Undefined did not require an active >change in that situation but everyone still seemed to understand the >notion that it was not to be trusted to have well determined value. In >those bad old days you were not even supposed to have DO loops with zero >counts as they often got you a single trip from such an undefined state. >See the "one trip" option on many comoilers to allow for this old "bug". > >> Maybe I'm not looking at the situation correctly or something, but those >> two things seem very different to me, but they both seem to fall under >> the "undefined" category in fortran. >> >> $.02 -Ron Shepard
From: Ron Shepard on 20 Jul 2010 00:44 In article <1jlvdte.1x1shw81e17jx0N%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > As "undefined" basically means "does not have a value according to the > standard" and to reference a variable means "to use its value", it is > sensible that referencing an undefined variable might be problematic. As I said before, I think this is all correct, but there is still this nagging issue that the variable had a defined value before, nothing was done to change that value, and afterwards the value is undefined. It seems to me this is different from most other situations in which values become undefined. Regarding the "processor dependent" designation, what harm or inconsistency would have been introduced if these kinds of values were designated by the standard as "processor dependent" rather than "undefined"? I'm assuming that referencing a processor dependent variable is NOT problematic (although the distinction in these cases is beyond me). To me, the situation is similar to the following: n = 1 call random_number(x) if ( x > 0.5 ) n = 2 After this sequence, the value of N is "processor dependent". [I think] That means it is alright to reference it and use its value, you just don't know which of the two values N has by looking at the code. Suppose that random_number() uses some truly random event (quantum transitions, or thermal noise) to set the value of x. In that case, not only does the programmer not know what is the value of N, but not even god could know (not to start a religious discussion, but by which I mean that it is fundamentally unknowable). That seems to be the same kind of situation for the N variable that is incremented within a function in those situations in which the processor can decide not to invoke the function. The processor's decision is not random, of course, but it has the same result in the end -- the bits in the variable depend on the processor (including compiler options), and you cannot simply look at the code alone and know which of the two legal possible values the variable will have. According to the standard, if the result is declared to be "undefined" you aren't even allowed to look to see which of the two possible (legal) values it has. $.02 -Ron Shepard
From: Richard Maine on 20 Jul 2010 01:24 Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > In article <1jlvdte.1x1shw81e17jx0N%nospam(a)see.signature>, > nospam(a)see.signature (Richard Maine) wrote: > > > As "undefined" basically means "does not have a value according to the > > standard" and to reference a variable means "to use its value", it is > > sensible that referencing an undefined variable might be problematic. > > As I said before, I think this is all correct, but there is still this > nagging issue that the variable had a defined value before, nothing was > done to change that value, and afterwards the value is undefined. Well, I don't know that I can adequately address your doubts, that being more a matter of perception than fact. I will say that I disagree with your description of nothing having been done to change the value. I can't off-hand think of any cases that fit that description. If we are still talking about the function side effect question, the function potentially changing the value is the whole point. The closest I can come to your description is that something was done that might or might not have changed the value and that I suppose you must be thinking of the case where it might not. But the standard considers both cases. > It > seems to me this is different from most other situations in which values > become undefined. I don't see the difference, but I also don't see how to argue such a question of perception. For example, I see it simillar to the way in which items in an input list become undefined if there was an I/O error. It seems likely that for most implementations each item would either have been sucessfully read or would still retain any prior value. The standard says they all become udefined. On your random_number example, note that the standard does say that the result of random_number is processor dependent. At least I think that's the way it describes it. If not, it is at least simillar in concept. But once the random number is returned, the processor-dependence is done with. Sure, in some sense, everything that is subsequently computed from a processor-dependent result could be said to be processor-dependent. But that standard doesn't describe things that way. Also recall my prior comment that I do see some inconsistencies in what is labelled as processor dependent versus what is labelled as undefined. I'm not going to defend it as being completely consistent, even if you happen to see different inconsistencies than I do. I'm not sure what difference it makes, though. If you are trying to argue that one of the concepts (undefined and processor dependent) should be eliminated, well... good luck, but my judgement is that ain't gonna happen. If you are trying to argue that some specific case should be changed from one of those concepts to the other to improve consistency, you might have more luck in some cases. But function side effects have so many different viewpoints that changing anything relating to them involves lots of debate (and quite often gets voted down just because the debate is endless and preventing anything from getting done). I'll not get involved. I was just trying to explain what "undefined" means. I will *NOT* let that slip over into yet another debate about what the standard does or should say about function side effects. Well, have the debate if you like, but it won't include me. > Regarding the "processor dependent" designation, what > harm or inconsistency would have been introduced if these kinds of > values were designated by the standard as "processor dependent" rather > than "undefined"? I'm assuming that referencing a processor dependent > variable is NOT problematic (although the distinction in these cases is > beyond me). I can't answer that other than to say that's clearly the way someone wrote it and got voted in. I'm not saying there would be no harm. I'm just saying I can't answer that. That could mean either that there is no good reason or that I don't know it. I'd believe either. There is *MORE* than enough question about what the standard does say without getting into what it might have said and why it didn't say those other things. The following para is the last thing I'll say along the lines of what might or might not have been. It is just far too speculative and there are far too many different viewpoints for it to be a very constructive line. Probably there are people with other viewpoints - almost certainly so. I will note that there can be issues other than that there are two (or more) possible values. Don't forget the possibility that the variable might not have been defined in the first place. If you say that the value is processor dependent, that means that it is not undefined; the two notions are incompatible. So specifying that the value was processor dependent would be saying that keeping its same state would not be an option in some cases. That doesn't seem reasonable to me. You'd have to at least add extra conditions to describe that option. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 20 Jul 2010 09:12 Richard Maine <nospam(a)see.signature> wrote: (snip on undefined or processor dependent) > I don't see the difference, but I also don't see how to argue such a > question of perception. For example, I see it simillar to the way in > which items in an input list become undefined if there was an I/O error. > It seems likely that for most implementations each item would either > have been sucessfully read or would still retain any prior value. The > standard says they all become udefined. Well, for the unformatted case I could see a case where some of the bytes were changed and some not. That could result in an illegal value, or otherwise something different than what was there and what would have been read in. Not so obvious for the formatted case. -- glen
From: Gordon Sande on 20 Jul 2010 10:13
On 2010-07-20 02:24:10 -0300, nospam(a)see.signature (Richard Maine) said: > Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: > >> In article <1jlvdte.1x1shw81e17jx0N%nospam(a)see.signature>, >> nospam(a)see.signature (Richard Maine) wrote: >> >>> As "undefined" basically means "does not have a value according to the >>> standard" and to reference a variable means "to use its value", it is >>> sensible that referencing an undefined variable might be problematic. >> >> As I said before, I think this is all correct, but there is still this >> nagging issue that the variable had a defined value before, nothing was >> done to change that value, and afterwards the value is undefined. Isn't processor dependent a property of the programm while undefined is a property of (really prohibition on) the programmer? Sometimes it is possible to also view undefined as a property of the program. This all relates back to the notion that the Fortran statndard is as much about what the programmer is allowed to do as what the program is expected to do. |