Functions with side effects
in [Fortran]
|
From: Louis Krupp on 19 Jul 2010 07:52 On 7/18/2010 11:42 PM, Ron Shepard wrote: > 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. > > 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. Someone please correct me if I'm wrong: It sounds like it doesn't matter if a function that sets a variable is called or not; once you execute a line of code in which the function might not be called due to optimization or short-circuiting or any other reason besides a straightforward reading of the code, then the *variable* becomes undefined, not its *value*. The value might or might not have changed, but I think the point is that once the value cannot be predicted without knowing implementation details which should be irrelevant, accessing that value is frowned upon, and I think that's what "undefined" means. Louis
From: Gordon Sande on 19 Jul 2010 08:14 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. 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: gmail-unlp on 19 Jul 2010 09:11 Hi again, I'll try to summarize what I've understood so far (thank you): 1) Assigning a value to a variable means or implies or is defining that variable. Thank you very much. While looking in the standard and posts in this thread I was realizing that nothing in the standard defines or identifies an undefined variable as non conformant on itself, I think the parts of the standard we have made reference to in the last posts just states when we have defined or undefined variables... in other parts, the standard states when undefinition implies non conformance... but maybe I'm wrong... 2) "redefine" or "become defined" should be taken just as "define", at least initially. 3) The original example could be considered as non standard compliant because of "Evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." in section 7.1.8, but one could argue that the evaluation of the function reference is not affected in any way by the evaluation of any other entity within the statement. The "detail" is that n becomes undefined for all of the reasons explained in previous posts. Before re-counter-arguing... I think there is a completely non standard compliant example: module foo implicit none integer :: n = 0 contains !------------------------ integer function f(k) integer, intent(in) :: k f = k n = n + 1 end function f !------------------------ integer function f2(k) integer, intent(in) :: k f2 = k**n n = n + 1 end function f2 !------------------------ end module foo program main use foo implicit none print *, f(3) + f(3) print *, f(3) + f2(3) print *, f2(3) + f2(4) print *, n end program main which is accepted at least by gfortran (version 4.1.2 20070925) -std=f2003 (I don't have ifort or another Fortran compiler at hand right now, but I could check). 4) "One thing you should understand is that it is moderately widely agreed that the standard is broken and inconsistent in this area. That's part of why you simply can't get a definitive answer - there isn't one. Different people have different ideas on the details of the brokenness and how best to fix it, or even whether it ought to be fixed." and, also, there are parts of the standard that some compilers just do not implement/enforce... as that of 3) above in gfortran? Thank you again, Fernando.
From: Dan Nagle on 19 Jul 2010 10:19 Hello, On 2010-07-19 07:52:19 -0400, Louis Krupp <lkrupp_nospam(a)indra.com.invalid> said: > ... I think the point is that once the value cannot be predicted without > knowing implementation details which should be irrelevant, accessing that > value is frowned upon, and I think that's what "undefined" means. This is my reading also. The standard takes the view that if the applications programmer codes according to the standard, then the compiler must preserve the illusion that the standard has been upheld. One can find instances where a variable will have some value, one just doesn't know which one, so the value is undefined. An example is the value of a variable on a read-list when an error occurs during the read operation. -- Cheers! Dan Nagle
From: glen herrmannsfeldt on 19 Jul 2010 12:09
Dan Nagle <dannagle(a)verizon.net> wrote: (snip) > On 2010-07-19 07:52:19 -0400, Louis Krupp > <lkrupp_nospam(a)indra.com.invalid> said: >> ... I think the point is that once the value cannot be predicted without >> knowing implementation details which should be irrelevant, accessing that >> value is frowned upon, and I think that's what "undefined" means. > This is my reading also. Some languages say something like "processor dependent" when a variable should have a legal, but undetermined, value. I don't know if Fortran has that distinction. > The standard takes the view that if the applications programmer > codes according to the standard, then the compiler must preserve > the illusion that the standard has been upheld. > One can find instances where a variable will have some value, > one just doesn't know which one, so the value is undefined. In that case, one could call it processor dependent. Not doing that allows for more choices, though I don't see them in this case. > An example is the value of a variable on a read-list when > an error occurs during the read operation. Well, in that case it could, for example, be a value with a parity error in memory, or other illegal value. (For VAX floating point the bit pattern for negative zero is a trap causing value.) -- glen |