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

**Learn more:Going Bananas lecture slide deck**

Ralf's blog

For the exercises/riddles in the slide deck:

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:

Exercises/riddles:

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

Code distribution:

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

Related Blog Post and Code:

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

]]>In this second lecture in the series, Ralf digs into

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

Welcome to another series of C9 Lectures covering functional programming. For this series, Dr. Ralf Lämmel has generously taken the time to produce videos for Channel 9 from his office at the University of Koblenz-Landau (Germany), where he is a professor of computer science. The idea here is to take the next step from Erik Meijer's fantastic introductory series on functional programming. Accordingly, Ralf's series will dive into more advanced areas of functional programming, again focusing on the Haskell language (the functional concepts here span beyond any one functional language, however).

To begin, Dr. Lämmel teaches us about the Expression Problem. Now put on your thinking caps, make yourself comfortable, and enjoy this installment of functional programming lectures on Channel 9. Huge thanks to Dr. Lämmel, both for doing this series for Channel 9 and for filming and producing it all by himself! Finally, thanks to Erik Meijer for suggesting this series and putting me in touch with Ralf.

See Dr. Lämmel's blog post about the new lecture series here: http://professor-fish.blogspot.com/2010/08/lecture-series-on-advanced-functional.html

[Homework assignment is on slide 26 -