Editing Side effect (computer science)

{{short description|Of a function, an additional effect besides returning a value}}
{{use dmy dates|date=December 2021|cs1-dates=y}}
{{use list-defined references|date=August 2022}}
{{redir|Hidden side effect|similar uses|hidden variable (disambiguation)}}
In [[computer science]], an operation, [[subroutine|function]] or [[expression (programming)|expression]] is said to have a '''side effect''' if it has any observable effect other than its primary effect of reading the value of its arguments and returning a value to the invoker of the operation. Example side effects include modifying a [[non-local variable]], a [[static local variable]] or a mutable argument [[Evaluation_strategy#Call by reference|passed by reference]]; raising errors or exceptions; performing [[I/O]]; or calling other functions with side-effects.<ref name="Spuler-Sajeev_1994"/> 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.<ref name="Hughes_1990"/><ref name="Collberg_2005"/>
Side effects play an important role in the design and analysis of [[programming language]]s. 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. 

[[Functional programming]] aims to minimize or eliminate side effects. The lack of side effects makes it easier to do [[formal verification]] of a program. The functional language [[Haskell (programming language)|Haskell]] eliminates side effects such as [[Input/output|I/O]] and other stateful computations by replacing them with [[Monad (functional programming)|monadic]] actions.<ref name="Haskell_1998"/><ref name="Jones-Wadler_1993"/> Functional languages such as [[Standard ML]], [[Scheme (programming language)|Scheme]] and [[Scala (programming language)|Scala]] do not restrict side effects, but it is customary for programmers to avoid them.<ref name="Felleisen_2014"/> 

[[Effect system]]s extend types to keep track of effects, permitting concise notation for functions with effects, while maintaining information about the extent and nature of side effects. In particular, functions without effects  correspond to pure functions.

[[Assembly language]] programmers must be aware of ''hidden'' side effects—instructions that modify parts of the processor state which are not mentioned in the instruction's mnemonic. A classic example of a hidden side effect is an arithmetic instruction that implicitly modifies [[status register|condition codes]] (a hidden side effect) while it explicitly modifies a [[processor register|register]] (the intended effect). One potential drawback of an [[instruction set]] with hidden side effects is that, if many instructions have side effects on a single piece of state, like condition codes, then the logic required to update that state sequentially may become a performance bottleneck. The problem is particularly acute on some processors designed with [[instruction pipeline|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 ==
{{Main|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 function|pure]], that is to say the expression must be [[deterministic algorithm|deterministic]] (always give the same [[value (computer science)|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. <code>sleep(5000)</code> or <code>for (int i = 0; i < 10000; ++i) {}</code>. These instructions do not change state other than taking an amount of time to complete.

== Idempotence ==
{{Main|Idempotence#Computer science meaning}}
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 [[Idempotence#Definition|mathematical sense]]. For instance, consider the following [[Python (programming language)|Python]] program:

<syntaxhighlight lang="python">
x = 0

def setx(n):
    global x
    x = n

setx(3)
assert x == 3
setx(3)
assert x == 3
</syntaxhighlight>

<code>setx</code> is idempotent because the second application of <code>setx</code> to 3 has the same effect on the system state as the first application: <code>x</code> 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 [[idempotence#Definition|mathematical sense]]. For instance, consider the following Python program:

<syntaxhighlight lang="python">
def abs(n):
    return -n if n < 0 else n

assert abs(abs(-3)) == abs(-3)
</syntaxhighlight>

<code>abs</code> is idempotent because the second application of <code>abs</code> 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 (programming language)|C]]. The assignment <code>a = b</code> is an expression that evaluates to the same value as the expression <code>b</code>, with the side effect of storing the [[value (computer science)#lrvalue|R-value]] of <code>b</code> into the [[value (computer science)#lrvalue|L-value]] of <code>a</code>. This allows multiple assignment:

<syntaxhighlight lang="c">
a = (b = 3);  // b = 3 evaluates to 3, which then gets assigned to a
</syntaxhighlight>

Because the operator [[operator associativity#Right-associativity of assignment operators|right associates]], this is equivalent to

<syntaxhighlight lang="c">
a = b = 3;
</syntaxhighlight>

This presents a potential hangup for novice programmers who may confuse

<syntaxhighlight lang="c">
while (b == 3) {}  // tests if b evaluates to 3
</syntaxhighlight>

with

<syntaxhighlight lang="c">
while (b = 3) {}  // b = 3 evaluates to 3, which then casts to true so the loop is infinite
</syntaxhighlight>

== See also ==
* [[Action at a distance (computer programming)]]
* [[Don't-care term]]
* [[Sequence point]]
* [[Side-channel attack]]
* [[Undefined behaviour]]
* [[Unspecified behaviour]]
* [[Frame problem]]

== References ==
{{Reflist|refs=
<ref name="Spuler-Sajeev_1994">{{cite book |title=Compiler Detection of Function Call Side Effects |author-last1=Spuler |author-first1=David A. |author-last2=Sajeev |author-first2=A. Sayed Muhammed |date=January 1994 |publisher=[[James Cook University]] |citeseerx=10.1.1.70.2096 |quote=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).}}</ref>
<ref name="Hughes_1990">{{cite book |title=Research Topics in Functional Programming |editor-first=David A. |editor-last=Turner |editor-link=David Turner (computer scientist) |publisher=[[Addison-Wesley]] |date=1990 |pages=17–42}} Via {{cite web |author-last=Hughes |author-first=John |title=Why Functional Programming Matters |url=http://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf |access-date=2022-08-06 |url-status=live |archive-url=https://web.archive.org/web/20220614042648/https://www.cs.utexas.edu/~shmat/courses/cs345/whyfp.pdf |archive-date=2022-06-14}}</ref>
<ref name="Collberg_2005">{{cite web |author-first=Christian S. |author-last=Collberg |date=2005-04-22 |title=CSc 520 Principles of Programming Languages |publisher=Department of Computer Science, [[University of Arizona]] |url=http://www.cs.arizona.edu/~collberg/Teaching/520/2005/Html/Html-24/index.html |access-date=2022-08-06 |archive-url=https://web.archive.org/web/20220806155136/https://www2.cs.arizona.edu/~collberg/Teaching/520/2005/Html/Html-24/index.html |archive-date=2022-08-06}}</ref>
<ref name="Felleisen_2014">{{cite web |author-first1=Matthias |author-last1=Felleisen |author-link1=Matthias Felleisen |author-first2=Robert Bruce |author-last2=Findler |author-first3=Matthew |author-last3=Flatt |author-first4=Shriram |author-last4=Krishnamurthi |author-link4=Shriram Krishnamurthi |title=How To Design Programs |publisher=[[MIT Press]] |date=2014-08-01 |edition=2 |url=http://www.htdp.org/}}</ref>
<ref name="Haskell_1998">{{cite web |title=Haskell 98 report |date=1998 |url=http://www.haskell.org}}</ref>
<ref name="Jones-Wadler_1993">{{cite conference |title=Imperative Functional Programming |author-first1=Simon Peyton |author-last1=Jones |author-first2=Phil |author-last2=Wadler |conference=Conference Record of the 20th Annual ACM Symposium on Principles of Programming Languages |pages=71–84 |date=1993}}</ref>
}}

{{Program analysis}}
{{DEFAULTSORT:Side Effect (Computer Science)}}
[[Category:Computer programming]]
[[Category:Programming language theory]]
[[Category:Functional programming]]
[[Category:Articles with example C code]]
[[Category:Articles with example Python (programming language) code]]