Side Effects in Functional Programming

Question

In a Functional Programming book the author mentions the following are the side effects.

1. Modifying a variable
2. Modifying a data structure in place
3. Setting a field on an object
4. Throwing an exception or halting with an error
5. Printing to the console or reading user input
6. Reading from or writing to a file
7. Drawing on the screen

I am just wondering how it is possible to write pure functional program without reading or writing to a file if they are side effects. If yes what would be the common approach in the functional world to achieve this ?

Thanks, Mohamed

Turnstone

I think it is impossible. We always program for side effects and the goal is not to perfectly avoid them because if you do not have any your program does not do anything at all :) The goal is write as much pure code as much you can and separate it as much as you can from the impure. – Granddaughter

Possible duplicate of How do functional languages model side-effects? – Diagnosis

To continue @cstuncsik's thought, we do this in part so that the impure code that's separated out is the part that we don't care to test - it's not "what we're writing". If we make all the rest (what "we're writing") pure, it's predictable/testable, and the surface of what's impure is minimized. – Inerrant

Answer 1

Properly answering this question requires likely an entire book (not too long). The point here is that functional programming is meant to separate logic description / representation from its actual runtime interpretation. Your functional code just represents (doesn't run) the effects of your program as values, giving you back some kind of abstract syntax tree that describes your computation. A different part of your code (usually called the interpreter) will take those values and lazily run the actual effects. That part is not functional.

How is it possible to write a pure functional program that is useful in any way? It is not possible. A pure functional program only heats up the CPU. It needs an impure part (the interpreter) that actually writes to disk or to the network. There are several important advantages in doing it that way. The pure functional part is easy to test (testing pure functions is easy), and the referentially transparent nature of pure functions makes easy to reason about your code locally, making the development process as a whole less buggy and more productive. It also offers elegant ways to deal with traditionally obfuscated defensive code.

So what is the common approach in the functional world to achieve side effects? As said, representing them using values, and then writing the code that interprets those values. A really good explanation of the whole process can be found in these blog post series.

Bloomers

Answer 2

For the sake of brevity, let me (over)simplify and make the long story short:

To deal with "side effects" in purely functional programming, you (programmers) write pure functions from the input to the output, and the system causes the side effects by applying those pure functions to the "real world".

For example, to read an integer x and write x+1, you (roughly speaking) write a function f(x) = x+1, and the system applies it to the real input and outputs its return value.

For another example, instead of raising an exception as a side effect, your pure function returns a special value representing the exception. Various "monads" such as IO in Haskell generalize these ideas, that is, represent side effects by pure functions (actual implementations are more complicated, of course).

Overabound