This book is an important landmark in the evolution of Haskell and functional programming.
When we speak of “functional” programming, we’re talking about mutation free computation: you can create all the new state you want; but you can’t mutate any existing state.
This has a number of advantages that don’t fall on deaf ears these days: one is that mutation free computations are automagically thread safe; which is music to the ears of anyone that’s had to grapple with threading, concurrency, or parallel programming issues.
However, another (perhaps more important consideration) is that when we don’t have mutation to worry about, we are free to do substitutions, and manipulate functions (a.k.a. “code”) in algebraic-like ways; and that is the focus of this book. Richard Bird is one of the pioneers of using equational reasoning to refactor existing code and to prove that one code expression is equivalent (or not equivalent) to a different code expression (wherein we are perhaps interested in reliability or improving performance without sacrificing semantic meaning). Or, to prove what a code expression really means; and to thereby be able to generalize it or otherwise reason about it.
If you are new to seeing code manipulated in algebraic-like ways, it can seem like black magic until one gets acclimated to thinking about code in a purely functional way; and Haskell, as a programming language, is uniquely suited to that task.
This book claims to be a replacement for other works, but it does not cover some material that was covered in past books which I consider very worthwhile.
In the way of disclosure I want to mention that I read this book cover to cover (including the index); but did not do any of the exercises (other than to read through them). I also read the following cover to cover: “Introduction to Functional Programming using Haskell second edition” (Bird) and “Algebra of Programming” (Bird, De Moor); both of which I thought were outstanding.
One criticism I have of this book is that in the last chapter’s concluding remarks, a pure functional style is recommended over monadic programming (especially when there is no concern about interacting with the outside world). That left me wanting more elaboration: there are many uses of monads; one being to “lift” partial functions to more sophisticated total counterparts (i.e. Maybe). Is there a “purely” functional equivalent for such purposes that is preferable to monads; or is that use of monads perfectly reasonable? (I presume the latter, but would have liked more discussion on the matter.) Also I would have liked to see more examples of how monadic programming can cause difficulties for equational reasoning that can be removed by refactoring to a more purely functional style. A past book did grapple with some negative aspects of monads (like the way they can cause problems when trying to compose them and enforce a coherent order in how things get evaluated). More material on the “sin bin” nature of monads and their potential overuse would be nice.
Another comment: I missed the material on bignums; albeit I think the approach taken in a prior publication was flawed because it didn’t “normalize” numbers from least significant (in head position) to most significant (which makes everything much harder, IMO).
I hope to see a sequel to this book as the author’s understanding (and the topic itself) evolve.