Functions with side effects
in [Fortran]
|
From: Richard Maine on 14 Jul 2010 16:16 Jan Gerrit Kootstra <jan.gerrit(a)kootstra.org.uk> wrote: > This not a side effect. > > This is what is called an operation on a global variable, for it is > defined outside the function. You appear to have a very narrow definition of "side effect". I can only guess that you must be restricting your definition to changes in the values of arguments. Most definitions include changes in any variables that are known outside of the function. That includes changes to global variables; indeed, that is often cited as one of the classic examples of a side effect. The Fortran standard doesn't actually define "side effect" as a term. That's more of an informal description that we tend to use as shorthand in discussing it. However, if one wants to use such a term in describing the limitations on Fortran functions, one needs to use a definition that goes along with those restrictions. > It is a totally legitimate result. See my quote to the contrary from the standard (not the quote about arguments, but the quote about "affect or be affected by"). Note that although the quote does use the term "effect", it does not use "side effect". As long as there is an effect, it is prohibitted, regardless of whether you want to call it "side" or not. > Rewriting your code with the statement in the main body would lead to this: [elided] That rewrite assumes an interpretation that the standard does not specify. The standard goes out of its way to be sure not to specify that. If, for example, the two invocations of the function were done in parallel, you would not necessarily get that result. Allowance of such things as parallel invocation is part of why the standard is specified the way it is. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: gmail-unlp on 14 Jul 2010 22:53 Hi, I'm trying to learn Fortran in general, and new standards (e.g. 2003) in particular, and this is why I find interesting this forum in general and this thread in particular. I have to say I'm rather lost with the statement from the F2003 standard: "Evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." Specifically, I can't define "affect": 1) "it's possible to evaluate", i.e. something as "makes no changes as to make impossible to evaluate the function", as it could be with "undefinition of an actual argument of the function" 2) "returns the same results", which I think it's hard to catch maybe only on PURE functions? However, I have another problem or misunderstanding, in section C.4.2 (Fortran 2003) " C.4.2 Evaluation of function references If more than one function reference appears in a statement, they may be executed in any order (subject to a function result being evaluated after the evaluation of its arguments) and their values shall not depend on the order of execution. This lack of dependence on order of evaluation permits parallel execution of the function references (7.1.8.1). " which is specifically on values. I've compiled this code 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 with gfortran 4.1.2 20070925 $> gfortran -std=f2003 ... which compiles, links and runs ok... and the order in which f2 functions are executed will define the returned value in the third print... Now, I think I'm losing something... Just a minor comment on "side effect": it's an old definition in software engineering, I'll copy from Wikipedia, since I think it's good enough (I don't know if somebody is going to change this definition, this is by July 14th, 2010): " In computer science, a function or expression is said to have a side effect if, in addition to producing a value, it also modifies some state or has an observable interaction with calling functions or the outside world. For example, a function might modify a global or a static variable, modify one of its arguments, raise an exception, write data to a display or file, or call other side-effecting functions. In the presence of side effects, a program's behavior depends on history; that is, the order of evaluation matters. " Fernando.
From: gmail-unlp on 14 Jul 2010 22:53 Hi, I'm trying to learn Fortran in general, and new standards (e.g. 2003) in particular, and this is why I find interesting this forum in general and this thread in particular. I have to say I'm rather lost with the statement from the F2003 standard: "Evaluation of a function reference shall neither affect nor be affected by the evaluation of any other entity within the statement." Specifically, I can't define "affect": 1) "it's possible to evaluate", i.e. something as "makes no changes as to make impossible to evaluate the function", as it could be with "undefinition of an actual argument of the function" 2) "returns the same results", which I think it's hard to catch maybe only on PURE functions? However, I have another problem or misunderstanding, in section C.4.2 (Fortran 2003) " C.4.2 Evaluation of function references If more than one function reference appears in a statement, they may be executed in any order (subject to a function result being evaluated after the evaluation of its arguments) and their values shall not depend on the order of execution. This lack of dependence on order of evaluation permits parallel execution of the function references (7.1.8.1). " which is specifically on values. I've compiled this code 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 with gfortran 4.1.2 20070925 $> gfortran -std=f2003 ... which compiles, links and runs ok... and the order in which f2 functions are executed will define the returned value in the third print... Now, I think I'm losing something... Just a minor comment on "side effect": it's an old definition in software engineering, I'll copy from Wikipedia, since I think it's good enough (I don't know if somebody is going to change this definition, this is by July 14th, 2010): " In computer science, a function or expression is said to have a side effect if, in addition to producing a value, it also modifies some state or has an observable interaction with calling functions or the outside world. For example, a function might modify a global or a static variable, modify one of its arguments, raise an exception, write data to a display or file, or call other side-effecting functions. In the presence of side effects, a program's behavior depends on history; that is, the order of evaluation matters. " Fernando.
From: nmm1 on 15 Jul 2010 02:52 In article <e5d947ff-5a2c-4c2e-ad49-a9b0843104e8(a)d8g2000yqf.googlegroups.com>, gmail-unlp <ftinetti(a)gmail.com> wrote: > >Just a minor comment on "side effect": it's an old definition in >software engineering, I'll copy from Wikipedia, since I think it's >good enough (I don't know if somebody is going to change this >definition, this is by July 14th, 2010): >" >In computer science, a function or expression is said to have a side >effect if, in addition to producing a value, it also modifies some >state or has an observable interaction with calling functions or the >outside world. For example, a function might modify a global or a >static variable, modify one of its arguments, raise an exception, >write data to a display or file, or call other side-effecting >functions. In the presence of side effects, a program's behavior >depends on history; that is, the order of evaluation matters. >" It's wrong, anyway, as you might expect. The last sentence applies only to C-like languages; for others (like Fortran), the behaviour is often undefined. As an aside, C90 was ambiguous in this area, and (under some circumstances) some compilers used the Fortran rules; C99 has specified serial execution. There are also other possibilities, other than order-dependence and undefined behaviour, but let's not get too arcane .... Regards, Nick Maclaren.
From: Richard Maine on 15 Jul 2010 03:01
<nmm1(a)cam.ac.uk> wrote: > In article <1jlmynl.in4i7r16uzqi6N%nospam(a)see.signature>, > Richard Maine <nospam(a)see.signature> wrote: > > > >Well, you aren't going to learn the fine points of function side effect > >issues from a usenet thread... > >One thing you should understand is that it is moderately widely agreed > >that the standard is broken and inconsistent in this area. > So far, we are agreed. > > >I recall a J3 meeting from nearly 2 decades ago where a presentation was > >made in committee about some of the brokenness. My (possibly flawed) > >recollection of the general reaction was something like... > > I very strongly disagree with that, and many other people did at the > time, and earlier and later. The problem isn't that it isn't very > serious, but that it's damn near unfixable, and the reason that you > may not have seen any pressure is precisely because the people who > had tried had given up and the new crop wasn't ripe. Just to clarify. I'm not saying I personally agreed with that position. I think I'll just abstain without trying to even advocate a personal position at all. I was just describing my perception of what I saw as the reaction of at least quite a few other people on the committee. Part of why I recall it so vividly is that it was not a reaction that I found pleasing. Of course, it is easy for that kind of perception of other people's opinions to be wrong, but do note that as being what I was attempting to describe. I have noticed that it is often hard to describe other people's opinions in a forum like this. First, of course, it can be nontrivial to accurately understand and describe someone else's opinions on a controversial matter. But even if you manage that part, people often then want to start arguing with you as though it were your own opinion. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |