Editing Functional programming (section)

===Purity===
Some functional languages allow expressions to yield actions in addition to return values. These actions are called ''side effects'' to emphasize that the return value is the most important outcome of a function (as opposed to the case in imperative programming). Languages that prohibit side effects are called [[pure]]. Even though some functional languages are impure they often contain a pure subset that is also useful as a programming language. It is usually beneficial to write a significant part of a functional program in a purely functional fashion and keep the code involving state and I/O to the minimum as impure code is more prone to errors.

====Immutable data====
Purely functional programs typically operate on ''immutable'' data. Instead of altering existing values, altered copies are created and the original is preserved. Since the unchanged parts of the structure cannot be modified, they can often be shared between the old and new copies, which saves memory.

====Referential transparency====
Pure computations yield the same value each time they are invoked. This property is called [[referential transparency]] and makes possible to conduct ''equational reasoning'' on the code. For instance if <hask>y = f x</hask> and <hask>g = h y y</hask> then we should be able to replace the definition of <hask>g</hask> with <hask>g = h (f x) (f x)</hask> and get the same result; only the efficiency might change.

====Lazy evaluation====
Since pure computations are referentially transparent they can be performed at any time and still yield the same result. This makes it possible to defer the computation of values until they are needed, that is, to compute them ''lazily''. [[Lazy evaluation]] avoids unnecessary computations and allows, for example, infinite data structures to be defined and used.

====Parallelism====
If a pure computation is referentially transparent then so are its sub-computations. This makes it much easier to run those pure sub-computations [[Parallelism|in parallel]] to obtain the result of the entire computation.

====Purity and effects====
Even though purely functional programming is very beneficial, the programmer might want to use features that are not available in pure programs, like efficient mutable arrays or convenient I/O. There are two approaches to this problem.

:{|
|
=====Side effects in the language=====
Some functional languages extend their purely functional core with side effects. The programmer must then ''always'' be careful not to use impure functions in places where only pure functions are expected.

=====Side effects through monads=====
Another way of introducing side effects to a pure language is to simulate them using [[monad]]s. While the language remains pure and referentially transparent, monads can provide implicit state by threading it inside them. The compiler does not even have to 'know' about the imperative features because the language itself remains pure, however usually the implementations do 'know' about them due to the efficiency reasons, for instance to provide <math>O(1)</math> mutable arrays.

Allowing side effects only through monads and keeping the language pure makes it possible to have lazy evaluation that does not conflict with the effects of impure code. Even though lazy expressions can be evaluated in any order, the monad structure forces the effects to occur in the correct order.
|}