Talk:Side effect (computer science)
|WikiProject Computer science||(Rated Start-class, Mid-importance)|
- 1 Naming
- 2 Functions without side-effects are idempotent?
- 3 side-effects are also I/O
- 4 not just functions
- 5 Explicit asignement is not a side effect
- 6 Looping forever/diverging and call-by-value
- 7 Removed "Safe operations are also idempotent, although the reverse is not necessarily true"
- 8 Focus! (and 'effects' versus 'side effects')
- 9 Propose removing the parts about machine instructions
- 10 Redundant
- 11 Side effects vs. pure
- 12 Example
In the future, this article should live at side effect (computer science)...
- Yes. The medical meaning is by far the most prominent. --Tarquin
Functions without side-effects are idempotent?
- No. Idempotence means it has the same effect whether used once or multiple times. Functions without side effects should have no side effect at all. --Spoon! 04:35, 22 October 2006 (UTC)
side-effects are also I/O
I think side effects are not just state, they are also I/O. More generally, any effect besides returning a value is a side-effect. Ideogram 19:27, 28 May 2006 (UTC)
not just functions
This article should not concentrate on functions; the concept extends to the evaluation of any expression. For instance, in C, the expression "x++" is side-effecting, as is the expression "getc(stdin)". — (talk) 17:17, 16 June 2006 (UTC)
- Wouldn't x++ be better listed as an example of a destructive update? --maru (talk) contribs 01:15, 21 June 2006 (UTC)
Explicit asignement is not a side effect
the article states that, in imperative programming, side effects make program work, however, if I'm not wrong, imperative programs can (or must) perfectly work without any side effects at all, by using just explicit asignement sentences ¿ isn't it ?
- I think so, but the article says imperative programming often uses side effects, not that it must use them to work at all. --Gwern (contribs) 23:34 22 February 2007 (GMT)
Looping forever/diverging and call-by-value
Is looping forever/diverging a side effect? This article states that only changes in state can be side effects, but I've heard others say (possibly mistakenly) that looping forever/divering is a side effect.
Also, do the evaluations of function/operator arguments caused by call-by-value evaluation strategies count as side effects? What if the evaluation of an argument loops forever?
- There's no complete professional consensus, but many scholars and programmers consider divergence (nontermination) not to be an effect. I think it's because all you can observe is that either your program terminates or it hasn't yet, and if the program is going to diverge, changing the order of evaluation doesn't change what you can observe. Norman Ramsey (talk) 02:54, 20 April 2009 (UTC)
Removed "Safe operations are also idempotent, although the reverse is not necessarily true"
I removed the sentence: "Safe operations are also idempotent, although the reverse is not necessarily true" since it's not true.
There seems to be some confusion between side-effect-free and idempotent. As described on idempotent a function f is idempotent if forall x: f(x) = f(f(x)). An example of such an idempotent function is round, e.g. round(2.233)=2=round(round(2.233)).
This doesn't have anything to do with the round function being side-effect-free. E.g. if the round function increased a global counter each time it was called, then it would still be idempotent but not side-effect-free. A function like f(x):=x+1 is not idempotent but it is side-effect-free.
Focus! (and 'effects' versus 'side effects')
I've narrowed the focus of the opening considerably. The article is still a bit of a mess because 'side effect' is not really a technical term (though it's definitely a popular one). In the definition I have tried to make things more precise by using the well-defined notion of an effect. The original author seems to have conflated this idea with another idea (side effect) meaning perhaps 'effect that was not manifest in the source code' or 'effect I didn't want'. A better article would distinguish these two ideas, but I don't know how. Norman Ramsey (talk) 02:57, 20 April 2009 (UTC)
Propose removing the parts about machine instructions
The stuff about CPUs and pipelines, while interesting, seems superfluous to an article on side effects. And in 2009, pipelined machines are very old news, and pipeline bubbles are not interesting. I think the article would be stronger and more focused if that paragraph were removed. What do others think? —Preceding unsigned comment added by Norman Ramsey (talk • contribs) 03:06, 20 April 2009 (UTC)
Side effects vs. pure
Reading the definition in the current article I don't think it's obvious if a side effect free function is always pure.
The current definition is:
"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."
Could interaction with the outside world be reading a global variable? The current article mentions "read data" as an example of a side effect.
In the section about Referential transparency a function is said to have referential transparency if it's side effect free and pure.
Pure is defined in a separate article as (my rephrasing): Independent of other inputs than given argument and side effect free.
But this article suggests that a side effect free function must not read data from the outside making pure and side effect free the same thing.
I've added some examples to demonstrate how side effects work in C++ with the assignment operator. It's somewhat of a rehash of the information found on the operator associativity page (so a link may be all that's required -- delete code if desired), but it's a little more specific to side effects and their gotchas. Glosser.ca (talk) 16:02, 7 November 2011 (UTC)