I often encounter the following statements / arguments:

  1. Pure functional programming languages do not allow side effects (and are therefore of little use in practice because any useful program does have side effects, e.g. when it interacts with the external world).
  2. Pure functional programming languages do not allow to write a program that maintains state (which makes programming very awkward because in many application you do need state).

I am not an expert in functional languages but here is what I have understood about these topics until now.

Regarding point 1, you can interact with the environment in purely functional languages but you have to explicitly mark the code (functions) that introduces side effects (e.g. in Haskell by means of monadic types). Also, as far as I know computing by side effects (destructively updating data) should also be possible (using monadic types?) even though it is not the preferred way of working.

Regarding point 2, as far as I know you can represent state by threading values through several computation steps (in Haskell, again, using monadic types) but I have no practical experience doing this and my understanding is rather vague.

So, are the two statements above correct in any sense or are they just misconceptions about purely functional languages? If they are misconceptions, how did they come about? Could you write a (possibly small) code snippet illustrating the Haskell idiomatic way to (1) implement side effects and (2) implement a computation with state?

  • 7
    I think most of this hinges on what you define a 'pure' functional language to be.
    – jk.
    Dec 19, 2012 at 9:36
  • @jk: To avoid the problem of defining 'pure' functional languages, assume purity in the Haskell sense (which is well-defined). Under which conditions a functional language can be considered 'pure' can be the topic of a future question.
    – Giorgio
    Dec 19, 2012 at 19:53
  • Both answers contain lots of clarifying ideas and it was difficult to me to choose which one to accept. I decided to accept sepp2k's answer because of the additional pseudo-code examples.
    – Giorgio
    Dec 20, 2012 at 21:05

2 Answers 2


For the purposes of this answer I define "purely functional language" to mean a functional language in which functions are referentially transparent, i.e. calling the same function multiple times with the same arguments will always produce the same results. This is, I believe, the usual definition of a purely functional language.

Pure functional programming languages do not allow side effects (and are therefore of little use in practice because any useful program does have side effects, e.g. when it interacts with the external world).

The easiest way to achieve referential transparency would indeed be to disallow side effects and there are indeed languages in which that is the case (mostly domain specific ones). However it is certainly not the only way and most general purpose purely functional languages (Haskell, Clean, ...) do allow side effect.

Also saying that a programming language without side effects is little use in practice isn't really fair I think - certainly not for domain specific languages, but even for general purpose languages, I'd imagine a language can be quite useful without providing side effects. Maybe not for console applications, but I think GUI applications can be nicely implemented without side-effects in, say, the functional reactive paradigm.

Regarding point 1, you can interact with the environment in purely functional languages but you have to explicitly mark the code (functions) that introduces them (e.g. in Haskell by means of monadic types).

That's a bit over simplifying it. Just having a system where side-effecting functions need to be marked as such (similar to const-correctness in C++, but with general side-effects) is not enough to ensure referential transparency. You need to ensure that a program can never call a function multiple times with the same arguments and get different results. You could either do that by making things like readLine be something that's not a function (that's what Haskell does with the IO monad) or you could make it impossible to call side-effecting functions multiple times with the same argument (that's what Clean does). In the latter case the compiler would ensure that every time you call a side-effecting function, you do so with a fresh argument, and it would reject any program where you pass the same argument to a side-effecting function twice.

Pure functional programming languages do not allow to write a program that maintains state (which makes programming very awkward because in many application you do need state).

Again, a purely functional language might very well disallow mutable state, but it's certainly possible to be pure and still have mutable state, if you implement it in the same way as I described with side-effects above. Really mutable state is just another form of side-effects.

That said, functional programming languages definitely do discourage mutable state - pure ones especially so. And I don't think that that makes programming awkward - quite the opposite. Sometimes (but not all that often) mutable state can't be avoided without losing performance or clarity (which is why languages like Haskell do have facilities for mutable state), but most often it can.

If they are misconceptions, how did they come about?

I think many people simply read "a function must produce the same result when called with the same arguments" and conclude from that that it's not possible to implement something like readLine or code that maintains mutable state. So they're simply not aware of the "cheats" that purely functional languages can use to introduce these things without breaking referential transparency.

Also mutable state is heavily discourages in functional languages, so it isn't all that much of a leap to assume it's not allowed at all in purely functional ones.

Could you write a (possibly small) code snippet illustrating the Haskell idiomatic way to (1) implement side effects and (2) implement a computation with state?

Here's an application in Pseudo-Haskell that asks the user for a name and greets him. Pseudo-Haskell is a language that I just invented, which has Haskell's IO system, but uses more conventional syntax, more descriptive function names and has no do-notation (as that would just distract from how exactly the IO monad works):

greet(name) = print("Hello, " ++ name ++ "!")
main = composeMonad(readLine, greet)

The clue here is that readLine is a value of type IO<String> and composeMonad is a function that takes an argument of type IO<T> (for some type T) and another argument that is a function which takes an argument of type T and returns a value of type IO<U> (for some type U). print is a function that takes a string and returns a value of type IO<void>.

A value of type IO<A> is a value that "encodes" a given action that produces a value of type A. composeMonad(m, f) produces a new IO value that encodes the action of m followed by the action of f(x), where x is the value produces by performing the action of m.

Mutable state would look like this:

counter = mutableVariable(0)
increaseCounter(cnt) =
    setIncreasedValue(oldValue) = setValue(cnt, oldValue + 1)
    composeMonad(getValue(cnt), setIncreasedValue)

printCounter(cnt) = composeMonad( getValue(cnt), print )

main = composeVoidMonad( increaseCounter(counter), printCounter(counter) )

Here mutableVariable is a function that takes value of any type T and produces a MutableVariable<T>. The function getValue takes MutableVariable and returns an IO<T> that produces its current value. setValue takes a MutableVariable<T> and a T and returns an IO<void> that sets the value. composeVoidMonad is the same as composeMonad except that the first argument is an IO that does not produce a sensible value and the second argument is another monad, not a function that returns a monad.

In Haskell there's some syntactic sugar, that makes this whole ordeal less painful, but it's still obvious that mutable state is something that language doesn't really want you to do.

  • Great answer, clarifying a lot of ideas. Should the last line of the code snippet use the name counter, i.e. increaseCounter(counter)?
    – Giorgio
    Dec 19, 2012 at 12:24
  • @Giorgio Yes, it should. Fixed.
    – sepp2k
    Dec 19, 2012 at 12:30
  • 1
    @Giorgio One thing I forgot to explicitly mention in my post is that the IO action returned by main will be the one that actually gets executed. Other than returning an IO from main there is no way to execute IO actions (without using horribly evil functions that have unsafe in their name).
    – sepp2k
    Dec 19, 2012 at 12:38
  • OK. scarfridge also mentioned destructing IO values. I did not understand whether he refers to pattern matching, i.e. to the fact that you can deconstruct values of an algebraic data type, but one cannot use pattern matching to do this with IO values.
    – Giorgio
    Dec 19, 2012 at 12:41

IMHO you are confused because there is a difference between a pure language and a pure function. Let us begin with the function. A function is pure if it will (given the same input) always return the same value and does not cause any observable side effects. Typical examples are mathematical functions like f(x) = x * x. Now consider an implementation of this function. It would be pure in most languages even those which are not generally considered pure functional languages e.g. ML. Even a Java or C++ method with this behavior can be considered as pure.

So what is a pure language? Strictly speaking one might expect that a pure language does not let you express functions that are not pure. Let us call this the idealistic definition of a pure language. Such a behavior is highly desirable. Why? Well the nice thing about a program consisting of only pure functions is that you can replace the function application with its value without changing the meaning of the program. This makes very easy to reason about programs because once you know the result you can forget the way it was computed. Purity might also allows the compiler to perform certain aggressive optimizations.

So what if you need some internal state? You can mimic state in a pure language simply by adding the state before the computation as an input parameter and the state after the computation as part of the result. Instead of Int -> Bool you get something like Int -> State -> (Bool, State). You simply make the dependency explicit (which is considered good practice in any programming paradigm). BTW there is a monad that is a particularly elegant way to combine such state-mimicking functions into bigger state-mimicking functions. This way you definitely can "maintain state" in a pure language. But you have to make it explicit.

So does this mean I can interact with the outside? After all a useful program must interact with the real world in order to be useful. But input and output are obviously not pure. Writing a specific byte to a specific file might be fine for the first time. But executing the exact same operation a second time might return an error because the disk is full. Clearly there exists no pure language (in the idealistic meaning) that can write to a file.

So we are faced with a dilemma. We want mostly pure functions but some side effects are absolutely required and those are not pure. Now a realistic definition of a pure language would be that there has to be some means to separate the pure parts from the other parts. The mechanism must ensure that no impure operation sneaks its way into the pure parts.

In Haskell this is done with the IO type. You cannot destruct an IO result (without unsafe mechanisms). Thus you can only process IO results with functions that are defined in the IO module themselves. Luckily there is a very flexible combinators which allows you to take an IO result and process it in a function as long as that function returns another IO result. This combinator is called bind (or >>=) and has the type IO a -> (a -> IO b) -> IO b. If you generalize this concept you arrive at the monad class and IO happens to be an instance of it.

  • 4
    I don't really see how Haskell (ignoring any function with unsafe in its name) does not meet your idealistic definition. There are no impure functions in Haskell (again ignoring unsafePerformIO and co.).
    – sepp2k
    Dec 19, 2012 at 11:59
  • 4
    readFile and writeFile will always return the same IO value, given the same arguments. So e.g. the two code snippets let x = writeFile "foo.txt" "bar" in x >> x and writeFile "foo.txt" "bar" >> writeFile "foo.txt" "bar" will do the same thing.
    – sepp2k
    Dec 19, 2012 at 14:02
  • 3
    @AidanCully What do you mean by "IO function"? A function that returns a value of type IO Something? If so, it is perfectly possible to call an IO function twice with the same argument: putStrLn "hello" >> putStrLn "hello" - here both calls to putStrLn have the same argument. Of course that's not a problem because, as I said earlier, both calls will result in the same IO value.
    – sepp2k
    Dec 19, 2012 at 14:24
  • 3
    @scarfridge Evaluating writeFile "foo.txt" "bar" can not cause an error because evaluating the function call does not execute the action. If you're saying that in my previous example the version with let has only one opportunity to cause an IO failure while the version without let has two, you're wrong. Both version have two opportunities for an IO failure. Since the let version evaluates the call to writeFile only once while the version without let evaluates it twice, you can see that it does not matter how often the function is called. It only matters how often the resulting...
    – sepp2k
    Dec 19, 2012 at 14:54
  • 6
    @AidanCully The "monad mechanism" does not pass around implicit parameters. The putStrLn function takes exactly one argument, which is of type String. If you don't believe me, look at its type: String -> IO (). It certainly doesn't take any arguments of type IO - it produces a value of that type.
    – sepp2k
    Dec 21, 2012 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.