Learning Functional Programming

Chapter 7. Where to from Here?

We have seen the various aspects of FP such as immutability, referential transparency, higher order functions, laziness, and pattern matching, and we have seen various methods of employing all these constructs in our code. What is the next level? How do we get there? There are a few ways we can proceed.

Taking the Pure Route

We have emphasized throughout the book that the more of these techniques we employ, “the more functional” our code becomes. But can code be “completely functional”? The answer is “kind of,” and we will describe precisely what this means. We call such code “purely functional code” or “pure functional code.” I will first deal with some low hanging fruit: print statements. There are a number of side effects that occur in most nontrivial programs. For example, writing to a file, printing to the console, opening a socket, throwing an exception. If our code has any of these, it is not purely functional.

What can we do about this? If we cannot keep side effects out of our code completely, at least we can quarantine all the necessary side effects to the outer border, as it were, of the program so it will be perfectly clear to anybody reading the program where the impure parts are. I use the phrase outer border metaphorically. It is a matter of isolating all the side effects in one part of the program that is easily distinguishable from the rest. We can think of these as the pure part of the program and the impure part. The impure part ...