Editing Side effect (computer science) (section)

{{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.