Side effect (computer science)
In
Side effects play an important role in the design and analysis of programming languages. The degree to which side effects are used depends on the programming paradigm. For example, imperative programming is commonly used to produce side effects, to update a system's state. By contrast, declarative programming is commonly used to report on the state of system, without side effects.
Referential transparency
Absence of side effects is a necessary, but not sufficient, condition for referential transparency. Referential transparency means that an expression (such as a function call) can be replaced with its value. This requires that the expression is pure, that is to say the expression must be deterministic (always give the same value for the same input) and side-effect free.
Temporal side effects
Side effects caused by the time taken for an operation to execute are usually ignored when discussing side effects and referential transparency. There are some cases, such as with hardware timing or testing, where operations are inserted specifically for their temporal side effects e.g. sleep(5000)
or for (int i = 0; i < 10000; ++i) {}
. These instructions do not change state other than taking an amount of time to complete.
Idempotence
A
x = 0
def setx(n):
global x
x = n
setx(3)
assert x == 3
setx(3)
assert x == 3
setx
is idempotent because the second application of setx
to 3 has the same effect on the system state as the first application: x
was already set to 3 after the first application, and it is still set to 3 after the second application.
A pure function is idempotent if it is idempotent in the mathematical sense. For instance, consider the following Python program:
def abs(n):
return -n if n < 0 else n
assert abs(abs(-3)) == abs(-3)
abs
is idempotent because the second application of abs
to the return value of the first application to -3 returns the same value as the first application to -3.
Example
One common demonstration of side effect behavior is that of the
a = b
is an expression that evaluates to the same value as the expression b
, with the side effect of storing the R-value of b
into the L-valuea
. This allows multiple assignment:
a = (b = 3); // b = 3 evaluates to 3, which then gets assigned to a
Because the operator right associates, this is equivalent to
a = b = 3;
This presents a potential hangup for novice programmers who may confuse
while (b == 3) {} // tests if b evaluates to 3
with
while (b = 3) {} // b = 3 evaluates to 3, which then casts to true so the loop is infinite
See also
- Action at a distance (computer programming)
- Don't-care term
- Sequence point
- Side-channel attack
- Undefined behaviour
- Unspecified behaviour
References
- CiteSeerX 10.1.1.70.2096.
The term Side effect refers to the modification of the nonlocal environment. Generally this happens when a function (or a procedure) modifies a global variable or arguments passed by reference parameters. But here are other ways in which the nonlocal environment can be modified. We consider the following causes of side effects through a function call: 1. Performing I/O. 2. Modifying global variables. 3. Modifying local permanent variables (like static variables in C). 4. Modifying an argument passed by reference. 5. Modifying a local variable, either automatic or static, of a function higher up in the function call sequence (usually via a pointer).
- ^ Turner, David A., ed. (1990). Research Topics in Functional Programming. Addison-Wesley. pp. 17–42. Via Hughes, John. "Why Functional Programming Matters" (PDF). Archived (PDF) from the original on 2022-06-14. Retrieved 2022-08-06.
- ^ Collberg, Christian S. (2005-04-22). "CSc 520 Principles of Programming Languages". Department of Computer Science, University of Arizona. Archived from the original on 2022-08-06. Retrieved 2022-08-06.
- ^ "Haskell 98 report". 1998.
- ^ Jones, Simon Peyton; Wadler, Phil (1993). Imperative Functional Programming. Conference Record of the 20th Annual ACM Symposium on Principles of Programming Languages. pp. 71–84.
- ^ Felleisen, Matthias; Findler, Robert Bruce; Flatt, Matthew; Krishnamurthi, Shriram (2014-08-01). "How To Design Programs" (2 ed.). MIT Press.