Thank you, Ralf!!!

C

posted by Charles

I just did a "monad" search on channel9, and this seems to be the best place for finding monad lectures. 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.

posted by user42

posted by head.in.the.box

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

posted by Richard.Hein

C

posted by Charles

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

posted by harlock123

posted by ShinNoNoir

posted by user42

C

posted by Charles

posted by RichardAlan

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 (http://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?]

posted by head.in.the.box

@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.

posted by exoteric

posted by user42

posted by ǃ

posted by head.in.the.box

posted by Todd

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":

http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#SCP04

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

http://homepages.cwi.nl/~ralf/sfp99.pdf

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:

http://academic.research.microsoft.com/Paper/150465.aspx

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

http://homepages.cwi.nl/~ralf/foal03/

Ralf

posted by user42