The Xmas break is a good time to catch up with things. At the functional lunch at work we’ve been working though the NICTA Haskell course exercises which take you through the implementation of many pieces of the Haskell libraries via a series of questions with associated tests. We’ve just done the parts on Functor, Applicative and Monad. The questions were all really interesting, but I felt I needed a better introduction to the material. Luckily I came across the online version of LearnYouAHAskell and the sections on Functors, Monads and more Monads which are very good introduction to the relationship between the various concepts. After reading generally, useful Monads such as the State Monad have numerous wiki pages devoted to them.
Of course in Haskell, Monads are not quite enough. When you write anything complicated, you end up needing to have multiple Monads (think IO and some other Monad such as the exception Monad), so it is also important to get a grip on Monad Transformers, which let you deal with a stack of Monads. There is a reasonable introduction to these on the Haskell wiki, and there is a list of the standard transformers on the typeclassopedia. Somehow the use of Monad Transformers still feels like magic, even when they are introduced one by one like in this paper.
Of course, you might ask why Monads actually matter and this blog post covers the four problems that Monads attempt to solve. Though I’m not sure I fully understood the Kleisli category.
Once you want to play with Haskell, the obvious tool to use is GHC. The really cool thing is that the source to GHC is available on GitHub, so you can look at the actual implementation of all of the Monads described in the previous articles. Linked form the Haskell wiki page are a few blog articles such as the 24 days of GHC extensions, which includes articles on the more experimental features such as Rank N types and Bang Patterns.
I very much enjoyed having more time to play with GHCi, the interactive REPL which sits on top of the GHC compiler. There were a few commands that I hadn’t noticed before, in particular the single stepping which allows you to set breakpoints that are triggered when a particular piece of code is evaluated (and with Haskell being a lazy language the point of evaluation is often not very clear). This would have made life a bit easier in the past. For example, in this blog post on the strictness of Monads, in the example the author uses trace to report when a thunk is evaluated. Using the stepper in GHCi, it is possible to get the debugger to show us this.
By setting breakpoints, we can see the laziness, and in particular that doSomethingElse is evaluated before doSomething without needing to change the code and use the trace printing.
Moreover, the debugger lets you see how much of the various data values have been evaluated as the printing in the debugger (using :print) does not force the evaluation. This makes it a really good way to understand the evaluation to whnf. You can force the evaluation too using the :force command, though this obviously changes the behaviour of the program you are debugging.
All considered I learned a lot about Haskell over the holiday. There are many papers and book still to read but the language continues to bring a lot of novel concepts out into the open. And it is hard not to find it fascinating.
Thirty years tapping a keyboard 