The IO Monad — laid bare

From the Functional Programming illustrated in Python series

But I don’t like Monads!

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”. …

Assignment as parameter binding

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

Can it be done in a purely functional form, without var = expr assignment? It certainly can.

Binding to function parameters

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

def myfunc(x):
... more stuff

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…

Function composition with wrapped values

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!

Road map

Simple function composition

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 2x²+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.

20 END

Fig 1: A program which halts

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? …

Brian Candler

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store