C9 Lectures: Dr. Ralf Lämmel - The Quick Essence of Functional Programming

Play C9 Lectures: Dr. Ralf Lämmel - The Quick Essence of Functional Programming
Sign in to queue


We had to cover monads eventually, and there are many great monad tutorials out there (see, for example, here: http://www.haskell.org/haskellwiki/Tutorials#Using_monads). In fact, there are web resources concerned solely with organizing the many monad tutorials available in the wild, and developing new monad tutorials seems to be a popular sport in the Haskell community.

Today, Ralf Lämmel's lecture goes back to the roots, essentially revisiting Wadler's "The essence of functional programming"—the 1992 paper that discovered monads and popularized their use in functional programming. Ralf Lämmel's lecture and accompanying code distribution show Wadler's seminal insight: those original scenarios and observations still make sense today. Indeed, Simon Marlow (a Haskell/GHC high priest @ MSR Cambridge) recently noted: "it's still the best monad tutorial" (see http://twitter.com/simonmar/status/21397398061).

Focusing on a few generically useful monads, Dr. Lämmel explains how the work within the interpretation domain. While the lecture also takes a look at the contemporary Haskell library for monads and monad transformers, there are obviously many monads and associated domains that cannot be covered this time. If you want to learn more about monads, then continue with state threads, IO, parsing, and concurrency (STM).

Slide deck:



Slide #4 (easy), #6 (modest), #13 (modest), #40 (hard)

Code distribution:


 Blog post:




Right click to download this episode

The Discussion

  • User profile image

    Monad. Monad. Monad. Smiley

    Thank you, Ralf!!!


  • User profile image

    Thank you Charles for getting this mission accomplished.

    I just did a "monad" search on channel9, and this seems to be the best place for finding monad lectures. Smiley It is just truly amazing how much people care about monads, and what sort of miracles you can do with them.

    So this is the reason why I opted for a kind of history lecture---to show people, more or less, how Haskell's monads came about. So this is not really interesting for people who already have a few monads in their arsenal. But it should be interesting for people who would like to get a simple intro to monads based on classic and seminal material.

    If anyone would like to work towards matching the Haskell code in the repository with F#, Scala code or other functional code, please go ahead, just subscribe to the open-source project, and/or get in touch with me.

  • User profile image

    After this lecture *nobody* can claim anymore that Monads are difficult. 

  • User profile image

    I keep getting a media failure ... Sad ... could just be my connection ... staying at a hotel.  I'll try downloading it I guess. 

    Edit:  Bah ... this is going to take an hour to download ... definitely the lousy "high speed" connection. 

  • User profile image

    @Richard.Hein: Yes. It's a network thing. Download.


  • User profile image



    I hate hotel internet connections, often enough my cell card is better than the internet connection in a hotel, As I stay in hotels at least 50% of the year this is a real problem...

    I find myself downloading everything when I get to the office just to watch later in the hotel...

  • User profile image

    The Tweet-link seems to be broken. Can anyone confirm?

  • User profile image

    c9 is still a bit in migration pain, I guess Smiley There are known issues with tagging, hit count, and yes the tweeting and facebook stuff doesn't work for me either.

  • User profile image

    @user42: Bug has been filed.Can't repro the Facebook issue, though. Can repro the Tweet issue...


  • User profile image

    I really I wish I could understand what this lecture is all about Sad 

  • User profile image

    @RichardAlan:perhaps watch the Haskell series first?

    Fundamentalist functional programmers are really, really lazy. Even more that Ruby programmers, they actually take the DNRY motto to the extreme limit. Whenever they see a pattern repeating in their code, they try to encapsulate it in a reusable abstraction.

    The interesting thing about Haskell and other advanced functional languages (http://en.wikipedia.org/wiki/Pure_type_system), is that you can also define abstractions over type constructors (not just over types as with generics in Eiffel, Java, C#, ...).

    Once you can do that you suddenly discover design patterns, in the case of this lecture monads, that you did not see before: "Aha, this piece of code is has precisely the same structure as that,".

    As with all cool concepts, in programming, it turns out that the mathematicians had long ago already discovered the same thing and called it "monads".

    Other patterns that Ralf talks and will talk about are initial algebras, final co-algebras, homomorphisms (bananas, folds, lenses, unfolds, ..). Going even further, Ralf's hobby is to scrap *all* your boilerplate (https://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/).

    Another favorite hobby of fundamentalist functional programmers is to write programs in so-called "point-free" style, that is, using as few "variables" as possible (http://www.haskell.org/haskellwiki/Pointfree). Ralf might entertain and awe the audience with some Perls (pun intended) in this category in future lectures.

    Anyway, this is just a long winded way of saying that all is going on is pattern matching. So don't despair, it is like thoseautosterograms, if you stare at it long enough, you will suddenly see it.

    [Hey Channel 9, where is the spell checking in the comments?]

  • User profile image

    @Eric: What's the next big functional programming technique(s) to hit the mainstream? I ask because you are in a position to create a self-fulfilling prophesy Smiley

    @Ralf: Thanks for the lecture. I still have to watch this a couple of times to get the monad transformers but at least now I have a rough picture of what you actually use these for.

  • User profile image

    @exoteric: the coverage of monad transformers was pretty minimal. Perhaps I should do a session soon where I solve some of the previous exercises/riddles. The one with the compound monad would be a nice exercise, indeed. One could look into the internals of the leveraged monad transformers and the result of composition and thereby understand that composition gives the same monad as the monolithic monad that one would define from scratch.


  • User profile image

    What about Lawvere theories?

  • User profile image

    @ǃ: If you crave that kind of gourmet theory, have a look athttp://wwwhome.cs.utwente.nl/~fokkinga/index.html#detail_0000003413

  • User profile image

    Thank you Ralf! As a self learner I have been scouring the net for resources on Haskell, particularly type classes such as Monad and friends. Plenty of good stuff out there but this really worked for me. Found your presentation and explanations wonderfully clear.
    Thanks again! Todd

  • User profile image

    @Todd: thank you! It's a pleasure to target the c9 audience with this lecture series.

    Monads are not at all complicated. In my experience, two things can go wrong with learning about monads. a) the explanation is too difficult, e.g., due to unnecessary references to category theory; b) the explanation is too low level.

    Wadler's paper, which I sort of executed (in part), motivates monads from a program development's point of view (in the sense of "suppose you have this sort of program, but now you need to accommodate this additional requirement; ok, and now try to generalize the solution through a parameterization technique").

    I am a big fan, generally, of using transformations as a tool for understanding programming techniques. There is the monadification transformation; it's not just good for explanation; it's actually useful in functional programming as a kind of refactoring.

    M. Erwig has written a wonderful paper about "monadification":


    I also did a short paper a long time ago with a bit about monadification:


    Wadler also alluded to different forms of reuse that are present in the scenarios for the different monads. I gave explicit names to those forms: data extension and selective code replacement. This also shows that even the monad topic has a strong link to the expression problem.

    Well, while we are at it; it is intriguing to notice that monad (transformer) composition actually gives you another dimension of program extension---in addition to data and operation extensions. One may think of that additional extension form as having to do with aspects.

    De Meuter has written a thought-provoking (and potentially very confusing) paper some time ago on the relationship between monads and AOP:


    I intended to clarify this relationship, but, in fact, the following paper is potentially even more confusing:



Add Your 2 Cents