Side effect (computer science)

Source: Wikipedia, the free encyclopedia.

In

I/O or calling other functions with side-effects.[1] In the presence of side effects, a program's behaviour may depend on history; that is, the order of evaluation matters. Understanding and debugging a function with side effects requires knowledge about the context and its possible histories.[2][3]

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.

Haskell eliminates side effects such as I/O and other stateful computations by replacing them with monadic actions.[4][5] Functional languages such as Standard ML, Scheme and Scala do not restrict side effects, but it is customary for programmers to avoid them.[6]

pipelining (since 1990) or with out-of-order execution
. Such a processor may require additional control circuitry to detect hidden side effects and stall the pipeline if the next instruction depends on the results of those 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

subroutine with side effects is idempotent if multiple applications of the subroutine have the same effect on the system state as a single application, in other words if the function from the system state space to itself associated with the subroutine is idempotent in the mathematical sense. For instance, consider the following Python
program:

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

assignment operator in C. The assignment 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-value
of a. 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

References