Why bananas, Ralf?

Banana is functional programming slang for "fold"—an application of the catamorphic recursion scheme most widely known in the higher-order list processing tradition of Bird-Meertens Formalism and the Squiggol community. Erik Meijer used to be known as the "banana man" because of his early research on the subject; he also co-authored the seminal paper with theoretical (categorical) foundations on the subject. Incidentally, the paper used the notation of so-called "banana brackets" (instead of using the plain string "foldr"), which sort of explains why we sometimes say bananas. There is no shortage of crazy paper titles on the subject, by the way: "Functional Programming with Bananas, Lenses, Envelopes, and Barbed Wire," "Bananas in Space: ...," "Dealing with large bananas," "Boxes go bananas: ...," "See more through lenses than bananas," etc.

More to the point, foldr is the Swiss Army Knife in functional programming. Monoidal reductions of lists or mapping over lists and many other list-processing idioms can be modeled with the regular recursion operator foldr. Even a beginning lecture on functional programming would have to discuss foldr. Not discussing foldr in a Haskell course, however, is like not discussing for loops in a C# course. Indeed, the lectures on Graham Hutton's introductory Haskell course covered the basics of foldr very well. However, a lot more interesting stuff concerning folds or, say, bananas becomes apparent when one becomes fluent in functional programming. For instance, foldr and friends suddenly make sense for container types other than the concrete list type. Foldr and friends even generalize to arbitrary algebraic datatypes in different ways. The combination of folds and monoids also helps us understand key aspects of parallel data processing. These are the more advanced banana subjects that are covered by Ralf Lämmel's lecture this time. He has also contributed a stack of bananas papers over the years, and he draws from that interest.

Learn more:

Going Bananas lecture slide deck 
Download source code for this lecture
Ralf's blog

For the exercises/riddles in the slide deck:

Slide number (complexity):

12 (medium)
18 (medium)
21 (medium)
23 (easy)
24 (hard)
31 (hard)
34 (easy)

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:

http://developers.svn.sourceforge.net/viewvc/developers/repository/ralfs-channel9-lectures/decks/monads.pdf

Exercises/riddles:

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

Code distribution:

http://developers.svn.sourceforge.net/viewvc/developers/repository/ralfs-channel9-lectures/code/monads/

 Blog post:

http://professor-fish.blogspot.com/2010/09/essence-of-essence-of-functional.html

More specifically, this lecture develops an interpreter for a simple functional programming language that contains Booleans, natural numbers, lambdas, and recursive lets. The interpreter is actually developed in a stepwise manner, which is why the lecture is called "Evolution of an Interpreter."

In each step, another construct is added and the impact of the extension onto the interpreter is analyzed. In this manner, several interesting programming techniques are exercised. For instance, the Maybe type constructor is pervasively used for dealing with partiality, and Haskell's fixed point combinator is used to model the semantics (i.e., interpretation) of recursive bindings.

This lecture also prepares us for some more advanced subjects. For instance, the next lecture in this series will cover the intriguing subject of monads while using interpretation as the application scenario. Soon, generalized folds (or bananas, according to Erik Meijer) will also be discussed (the folds will traverse abstract syntax trees as opposed to lists).

Enjoy. Learn.

Thanks to Ralf for providing another excellent lecture!

Earlier lectures here.

Slides: https://developers.svn.sourceforge.net/svnroot/developers/repository/ralfs-channel9-lectures/decks/interpretation.pdf

http://professor-fish.blogspot.com/2010/08/bunch-of-interpreters-using-cpp-and.html

Type classes also take functional or declarative programming to a whole new level—one may define relations and functions pointwisely on types. That is, in the same way a regular function pattern matches on value structure, a type-level function sort of matches on type-definitional structure. This is quite a mouthful, I know.

There are various extensibility scenarios in the neighborhood of the Expression Problem that are interesting to consider from a design perspective, including several also addressable with type classes, and others that aren't. Look for the riddles (there are indeed several riddles in this lecture); many of them call for a discussion, rather than a straight solution. But beware—some of them are really difficult.

Thank you, Ralf, for another great lecture!

Get the slides for this lecture.

Enjoy! Learn!

See Lecture 1 - The Expression Problem