Tuesday, May 4, 2010

Side effects and functional programming

What are side effects in programming?

When we call a function in a typical programming language (C, C++, Java, Python, etc.), the function gets some input arguments and returns an output value.

  • The function has some local variables which are lost after the function execution completes (no side effect)
  • The function may compute a value which it returns (no side effect)
  • If the arguments are references/pointers to some objects, the function may modify them (a side effect to the input arguments)
  • The function may modify some global variable (a side effect)
  • The function may output something on output or to a file or a socket (a side effect to the outside world with which the program is associated)
  • The function may read something from input or from a file or a socket (a side effect to the outside world with which the program is associated)
  • A member function may alter the state of the object with which it is associated (a side effect)

Essentially if the function is touching anything apart from computing a simple result and returning it, then the function is causing some form of side effect.

What is functional programming?

Functional programming is a programming paradigm where functions are free from side effects. i.e. they take some input values as arguments and generate an output value as result and do nothing else. They don't touch anything in the outside world.

This approach is useful since this allows for easy composition of functions to create more powerful functionality without worrying about any side effects. Since the functions don't have any side effects, hence their behavior are well understood and combining them becomes straight-forward. If you think about it, side-effect free functions are very close to mathematical functions (a mapping from a domain to a range thats all).

Can we live without side effects?

No. All kinds of IO is side effects. Most useful software requires some form of IO (files, networks, databases, GUIs, you name it). Hence a programming paradigm which doesn't support side-effects, is pretty much useless.

How functional programming works then?

So here is the trick. A well designed functional programming language has two parts. One part focuses on side effects (its a small part), while the rest of the language provides extensive support for pure functional programming (side-effect free). The program design focuses on clear separation between side-effect free computations and side-effect full user/system interfaces. The full power of techniques like currying, higher order functions, lazy evaluation, etc. is utilized in the functional part.

An example?

Here is a simple example which shows how to compute the square of a given number (in Haskell).

square x = x * x

main = print $ square 4

square is a function which computes the square of a given number. This is a side-effect free function. main uses this function to compute the square of four and print on standard output. main is side-effect full.

The language requires that effect free functions cannot call effect full functions while effect full functions can call other effect full functions as well as effect free functions. Thus the effect free part of the program is completely segregated.

No comments: