*From the **Functional Programming illustrated in Python** series*

Monads, Monads, Monads… have you got anything without Monads?

Well, there’s Direct Function Application. That doesn’t have much Monad in it.

The problem is, functions don’t *do* anything. Sooner or later you’re going to want to write a program which interacts with the real world. It reads and writes to the terminal. It writes to the filesystem. It updates a SQL database. It turns a little red LED on and off. All of these things are decidedly stateful and side-effect-ful, and they are implemented in dirty, impure languages like C and ultimately machine code. That code needs to be boxed up and presented in a functional way in order to interact safely with functional code. …

*From the **Functional Programming illustrated in Python** series*

If you’re reading about functional programming, sooner or later you’re going to come across Monads. People seem to find Monads a very difficult topic to understand, so strap yourself in for a bumpy ride.

Err, no. I already covered Monads back in part 2 of this series. Move along please — nothing to see here. Go back and read part 2 again if you need to.

Actually, all I did there was write some code involving indirect application of functions to wrapped values, and I avoided using the M-word. Maybe the code contained a Monad, maybe it didn’t. The code works, and I hope you understood it. Does it even matter what it’s called? You can still enjoy a burrito, even if you don’t know that it’s called “a burrito”. …

*From the **Functional Programming illustrated in Python** series*

Consider the following sequence of computations, using assignment to temporary variables:

`v0 = 4`

v1 = v0*v0

v2 = 2*v1

v3 = 1+v2

print(v3)

Can it be done in a purely functional form, without `var = expr`

assignment? It certainly can.

When we invoke a function, its parameters are set (“bound”) to the arguments passed. For example:

def myfunc(x):

... more stuffmyfunc(5)

During the execution of `myfunc`

*x* is bound to the value 5. Eliminating the named function using a lambda, and split over multiple lines for clarity, this becomes:

`(lambda x:`

... more stuff…

*From the **Functional Programming illustrated in Python** series*

In the previous article, I showed three functions *f*, *g* and *h*, applied in that order to a value. There were several ways to achieve that. One was to nest them, giving “inside out” evaluation:

`result = h(g(f(v0)))`

Another was to assign to intermediate variables, so that the program flows top-to-bottom:

`v1 = f(v0)`

v2 = g(v1)

v3 = h(v2)

And a third was to wrap the value, where the wrapper class has an operator which applies the function on the right to the value on the left.

`result = Value(v0) >> f >> g >>…`

Welcome to a short series of articles which introduce functional programming concepts in a simple, easy-to-digest and non-mathematical way.

I have chosen Python because it’s familiar to many people. Whilst not generally considered a “functional” language, it has the tools needed to show the concepts clearly. It’s also comforting — it doesn’t have lots of brackets like Lisp, or almost no brackets at all like Haskell, and it has a good old `print()`

function!

*From the **Functional Programming illustrated in Python** series*

Functions calculate values from values. In the simplest case, to combine functions you would take the output from one function and use it as the input to another function.

I am going to take a very simple example:

- The first function
*f()*calculates the square of its input - The second function
*g()*doubles its input - The third function
*h()*adds one to its input

By applying the functions in this order, we can calculate 2*x*²+1.

This is very simple. We start with an input value of 4, square it (16), double it (32), and add one — giving the answer 33. …

One of the fundamental results from computer science is The Halting Problem, which roughly stated, says that there is no general way to determine whether a given program with a given input will either terminate in a finite time, or run forever.

`10 PRINT "HELLO"`

20 END

*Fig 1: A program which halts*

`10 PRINT "HELLO"`

20 GOTO 10

*Fig 2: A program which never halts*

It has been formally proved that there is no general solution to the Halting Problem — that is, there is no algorithm which can analyse *every* program and tell you for sure whether it halts or not. If you are a programmer, this sounds like a depressing result. Much of software engineering practice is devoted to the reduction of bugs — but what chance do you have of proving that your program returns the right answer, if in general you can’t even prove that it terminates? …