Functions with side effects
in [Fortran]
|
From: Richard Maine on 17 Jul 2010 22:20 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. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: ttw6687 on 18 Jul 2010 09:01 "Undefined" does not mean "NaN" (and whatever the INTEGER equivalent would be were there such.) In practice (for instrumenting programs), I have found it easier to use few (and often no) user defined functions. The only side effect (of this programming style) is that some programs end up looking like Lisp coded in Fortran. The worst use of side effects that I have seen was by some system programmers who would use a function to do things like write to a disk or something similar and use the result of the function as a flag or perhaps as the number of items transferred. Converting a subroutine that returns a status argument into a function that returns the status as the result of the function do not lead to equivalent programs.
From: glen herrmannsfeldt on 18 Jul 2010 12:30 Richard Maine <nospam(a)see.signature> wrote: (snip) > I've seen oodles of code with functions that had side effects. Heck, I > used to write a lot myself. I'd have many of my procedures written as > functions that returned an error indication because it shortened > call read_some_data(some_args,error) > if (error) then ... > into > if (.not. read_some_data(some_args)) then ... Fairly common in C. Even more common are functions that return other codes, such as EOF indicators. while(fgets(buf,sizeof(buf),in)) { /* do something with a line read in */ } which will loop until either EOF or an error condition occurs. > Eventually I repented my sins and converted all that stuff to > subroutines, partly to avoid questions of standard conformance with the > side effects, (snip) > I've seen many people with styles simillar to my old one though, where > many procedures are functions that return an error code of some kind, > with all the "real" purpose of the functions being in the side effects. > This style seems particularly common with those corrupted by C. > Fortunately, this kind of usage is not horribly prone to geting > optimized in ways that break it, as long as one doesn't do things like > reference them multiple times in the same statement. Note that C also has rules about side effects, though not quite the same as Fortran. Mostly that it doesn't specify the order that the functions are evaluated in if more than one are in the same statement. (Between sequence points in C, but most of the time sequence points are statement boundaries.) C doesn't tend to optimize out function calls, as most such wouldn't be allowed by the standard. (Not counting short circuit evaluation of logical expressions, which is required by the standard.) > Of course, as I've mentioned before, if you have a function that > is only ever referenced as > error = my_function(args) > you aren't making use of it being a function, and it might as well be a > subroutine. (To me, a major functionality of functions is that you can > reference them in expressions; if you restrict yourself to the trivial > expression that consists of only the function reference, then that isn't > worth much). Well, for C with call by value it makes slightly more sense. (And also that C doesn't have subroutines, void functions still count as functions.) Too much C code ignores the return values of such functions, though. -- glen
From: nmm1 on 18 Jul 2010 12:48 In article <i1va6s$om5$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Richard Maine <nospam(a)see.signature> wrote: > >> Eventually I repented my sins and converted all that stuff to >> subroutines, partly to avoid questions of standard conformance with the >> side effects, I have changed, too, but the underlying reason is that the conventional interpretation of Fortran has changed. What was accepted to be valid 40 years ago isn't today. >Note that C also has rules about side effects, though not quite >the same as Fortran. Mostly that it doesn't specify the order >that the functions are evaluated in if more than one are in the >same statement. (Between sequence points in C, but most of the >time sequence points are statement boundaries.) C doesn't tend >to optimize out function calls, as most such wouldn't be allowed >by the standard. (Not counting short circuit evaluation of logical >expressions, which is required by the standard.) In C90, it wasn't stated explicitly that such functions had to be called serially, and at least one compiler overlapped them - until too many of its customers screamed. C99 has explicitly stated the 'no optimisation of function calls' rule, though not to the same extent that C++ assumes and arguably implies. I believe that this could be done properly, but probably not starting from here :-( Regards, Nick Maclaren.
From: Ron Shepard on 19 Jul 2010 01:42
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. $.02 -Ron Shepard |