Patterns in Functional Programming

The good news is that Jeremy Gibbons is writing a book on Patterns in Functional Programming. Even better news is that he is blogging about it as he goes along!

Those unfamiliar with the topic may want to begin at the beginning, though I personally just rummaged around. Some may enjoy going to the papers rather than the blog, or even better to the LtU discussions about many of them. Alternatively, I think it might be a great opportunity to ask Jeremy questions using the comments on his blog. I am sure this can be a very productive learning experience, and will surely help the book!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Needs a ton of work

Loved his scala paper with Bruno Oliveira, which he linked to on his blog, but his writing quality here is more stream of consciousness and thousand fountains of thought bursting forth ink than a cogent, directed story. I guess he is learning a book is very different from a paper.

I am curious what Jeremy thinks of the pre-existing functional programming patterns literature, like Thomas Kuhne's thesis, since he seems to limit his posts to that. For example, Kuhne's Transfold and Kiselyov's Superfold.

Likewise I have spent a lot of time lately looking at real-time embedded design patterns and functional techniques for describing discrete and continuous reactive systems, since there is a great deal of overlap in control theory - but very poor explanations of the control phenomena.


I've had this post open in a browser window for a month, awaiting a proper response—apologies for tardiness. I looked at Kühne's work with great interest when the book and the ECOOP paper on Transfold came out, but it's been a while, and I've had to go back to them to remind myself what was in there.

The general argument of Kühne's book is in some sense dual to what I'm planning to do in my book. Kühne's thesis is that "design patterns inspired by FP concepts can advance OO design". I'll buy this; indeed, I've written about the same thesis myself (and, I fear, not always remembered to cite Kühne in the process). But if you like, the thesis in my book will be technology transfer in the opposite direction—that "the idea of design patterns from OO has an analogue in FP", namely higher-order recursion operators like fold.

As for Transfold itself, I have to confess that I was somewhat disappointed. The idea here is to handle iteration by flattening a collection to a lazy list, and to support simultaneous iteration over multiple streams by zipping them together (transposition). Flattening a collection explains consumption by iteration, but not production by iteration, and in particular, not structure-preserving maps over a collection; this point is made in the Essence of the Iterator Pattern paper with Bruno Oliveira. Transposition explains lockstep consumption of multiple streams, but not asynchronous consumption, as is required for merging. Most of all, I would expect the "right" collection of operators to enjoy a rich collection of laws to support reasoning, and Kühne doesn't address this except in passing. (Of course, if you want any useful laws at all, that basically rules out mainstream OO programming :-)

Oh, and I'm painfully aware that there's still a ton of work to be done! The blog is indeed just notes and thoughts, not polished prose—basically, I'm fishing for comments.

apropos functional programming patterns

Another LtU member is blogging on monadic design patterns on the web. This is a Scala oriented exposition, accompanying the writing of a book on said matter. It all does look very promising.

"secret" code for donors?


If it wasn't for the fact I know Greg is a smart guy, then I'd laugh this off.

But maybe Greg can explain why some code shouldn't be in a book intended to illuminate.

And what about concurrency?

If you add concurrency to a functional language in a declarative way, you get the very powerful property "functional patterns are concurrency patterns". I hope he gets around to talking about this kind of thing! Functional languages need to get out of the sequential straitjacket.

Of course

You may find Bob Harper's musings on the subject interesting -- although he would probably object to your use of terminology like "deterministic concurrency" as a contradiction in terms.