Lambda the Ultimate Pattern Factory: GoF patterns read as Haskell type classes

The premise: patterns that the functional languages already have

The author opens with a personal origin story that is also the thesis.

My first programming languages were Lisp, Scheme, and ML. When I later started to work in OO languages like C++ and Java I noticed that idioms that are standard vocabulary in functional programming were not so easy to achieve and required sophisticated structures. Books like Design Patterns: Elements of Reusable Object-Oriented Software were a great starting point to reason about those structures.

And then the observation that makes the whole project worth doing. One of the earliest findings was that several of the GoF patterns had a stark resemblance of structures that are built into in functional languages, for instance the strategy pattern corresponds to higher order functions in functional programming.

The trigger for writing it down was a re-read of the Typeclassopedia. The author thought it would be a good exercise to map the structure of software design patterns to the concepts found in the Haskell type class library and in functional programming in general. And the justification for doing it at all is a search result: by searching the web the author found some blog entries studying specific patterns, but did not come across any comprehensive study, and as it seemed that nobody did this kind of work yet, it was found worthy to spend some time on it.

So the genre is unusual and worth naming. It is not a tutorial and it is not a reference implementation. It is an essay that treats the GoF catalogue as a set of questions to ask about type classes, and the answers are the chapter headings: Data Transfer Object to Functor, Singleton to Applicative, Pipeline to Monad, NullObject to Maybe Monad, Interpreter to Reader Monad, Aspect Weaving to Monad Transformers, Composite to SemiGroup to Monoid, Visitor to Foldable, Iterator to Traversable, The Pattern behind the Patterns to Category, and Fluent Api to Comonad.

The three named audiences are equally specific. A programmer with an OO background who wants to get a better grip on how to implement more complex designs in functional programming. A functional programmer who wants a deeper intuition for type classes. And someone studying the Typeclassopedia who is looking for an accompanying reading with example use cases and working code.

The chapter list is the argument

The table of contents is long enough to show that this is a systematic treatment rather than a handful of examples, and the structure of it is revealing.

The core section is called the Patternopedia, and it goes through the Typeclassopedia type classes in order of how general they are. Data Transfer Object to Functor, then Singleton to Applicative, then Pipeline to Monad. Then the ones that are less obvious: NullObject to Maybe Monad, which is the observation that the null object pattern is what the Maybe monad does for absence. Interpreter to Reader Monad, which is the same idea in the evaluator direction. Aspect Weaving to Monad Transformers, which is a genuinely good match, since an effect stack is a way of composing concerns around a computation. Composite to SemiGroup to Monoid, Visitor to Foldable, and Iterator to Traversable.

Then a chapter called The Pattern behind the Patterns to Category, which is the general one, and Fluent Api to Comonad, which is the most speculative.

After the Patternopedia there is a section titled Beyond type class patterns, and it covers four GoF patterns that do not have a type class counterpart: Dependency Injection to Parameter Binding and Partial Application, Command to Functions as First Class Citizens, Adapter to Function Composition, and Template Method to type class default functions. Two more are handled under a creational heading: Abstract Factory to functions as data type values, and Builder to record syntax and smart constructor.

And then a Functional Programming Patterns section that runs the mapping in the other direction, with Higher Order Functions, Map Reduce, Lazy Evaluation and Reflection.

That structure is itself an argument, and a good one. The existence of a Beyond type class patterns section, with the four patterns that do not fit, is the most honest thing in the table of contents. A catalogue that mapped everything would be suspicious, because there are things in the GoF book that are simply the absence of a language feature, and a mapping exercise that acknowledged that would be more useful rather than less.

There is also a telling detail in the source. Several entries in the table of contents are commented out, including the ones for MonadFail, MonadFix, Alternative and MonadPlus, ArrowPlus, Bifunctor and Arrow. Those are the pairings the author has not written yet, and the fact that they are left in the source as comments rather than deleted suggests a plan to fill them in.

How a chapter is written, taking the DTO to Functor one

The chapters follow a consistent shape, and the Data Transfer Object to Functor entry shows it well.

Each chapter opens with a definition, and the DTO one quotes Wikipedia directly: in the field of programming a data transfer object is an object that carries data between processes, the motivation being that communication between processes is usually done resorting to remote interfaces such as web services where each call is an expensive operation. Because the majority of the cost of each call is related to the round-trip time between the client and the server, one way of reducing the number of calls is to use an object that aggregates the data that would have been transferred by the several calls, but that is served by one call only.

Then the attribution to Martin Fowler's Patterns of Enterprise Application Architecture, and the note that it is typically used in multi-layered applications where data is transferred between backends and frontends.

Then the concrete example, which is where the chapter earns its keep. The aggregation of data usually also involves a denormalization of data structures, and the chapter refers to a diagram where two entities from the backend, an Album and an Artist, are assembled to a compound denormalized DTO, an AlbumDTO.

And then the inverse mapping, which is where the Typeclassopedia reading begins, with the sentence in the source cut off at the word inverse.

The method is consistent across the book. Define the pattern, cite where it comes from, show a diagram or a concrete entity example, then read it back as a type class. That order matters, because the argument is never that the type class is a nicer name for the pattern. It is that the pattern is a way of building the type class, and the Haskell side usually has the structure already built in.

The reference chart is included for the same reason. A diagram of the relationships among the covered type classes is included, with solid arrows pointing from the general to the specific, meaning that if there is an arrow from Foo to Bar then every Bar is, or should be, or can be made into, a Foo. Dotted lines indicate some other sort of relationship. Monad and ArrowApply are noted as equivalent, and Apply and Comonad are greyed out since they are not actually, yet, in the standard Haskell libraries.

That last note is a small but telling detail, because it dates the essay to a specific point in the libraries and flags a case where the mapping is not yet settled in the language itself.

The reverse direction, and what the essay is not

The last two sections of the table of contents turn the exercise around, and that is the part that makes the project more than a lookup table.

The Functional Programming Patterns section maps the other way, listing Higher Order Functions, Map Reduce, Lazy Evaluation and Reflection, and the entries in the source for Continuation Passing and Functional Reactive Programming are commented out alongside the type class ones. So the essay is not only saying that patterns correspond to type classes, it is also working out which functional idioms have a pattern-shaped history in the object oriented world, which is a harder question because most of them predate the patterns.

There is a Conclusions section and a Some related links section, and the presence of both tells you the author expects the reader to leave with a position rather than a list.

What this project is not is worth stating clearly, because the name invites a wrong reading. It is not a library, there is nothing to install and no published package, and there are no GitHub releases. It is not a study of design patterns in the abstract either, because every chapter is anchored to a specific pattern and a specific type class. And it is not a replacement for either the GoF book or the Typeclassopedia, both of which it treats as prerequisites rather than as material to be replaced.

It is a translation between two vocabularies, and the value of a translation is highest for the reader who already knows one of them. A person who knows neither reads it as an introduction to type classes with examples drawn from patterns they have not met, which is a harder path than starting from the Typeclassopedia itself. A person who knows the patterns reads it as a series of answers to a question they had not thought to ask, and that is where the insight sits.

The author's own framing supports that reading. The project is work in progress, and the request is for corrections, adjustments, comments, suggestions and additional ideas through the issue tracker, which is the way an essay invites argument about its claims rather than just bug reports about its code.

The one practical caution is that this is one person's interpretation, presented as a set of correspondences that hold well enough to be useful. A mapping between a pattern and a type class is an argument, and like any argument it can be made more or less persuasive depending on the examples chosen. The chapters that quote Wikipedia and Fowler for the pattern side and then show the Haskell for the other side are the ones where the claim is easiest to check, and they are the ones the essay consistently leads with.

The repository is an essay in a Haskell package wrapper

The top level of the repository is small, and the shape tells you what kind of artefact this is.

There is the README, the `LICENSE` file, a `LtuPatternFactory.cabal` file, a `package.yaml` file, a `stack.yaml` file, a `src/` directory, a `renovate.json` and a `.github/` directory with a Haskell CI workflow, whose badge reads Haskell CI.

So the Haskell packaging is real. There is a Cabal file and a stack configuration, which means the code in `src/` is a Haskell library and the README is its documentation. The `package.yaml` is the hpack format that generates the Cabal file, so the source of truth for the package metadata is the YAML and the Cabal file is derived from it.

The `renovate.json` is the dependency update configuration, which is the mechanism that keeps the Haskell dependency set current without manual intervention, and the CI badge means the examples are compiled on every push. That last part matters for an essay, because a mapping backed by code that does not compile is a blog post, and a mapping backed by code that is built in CI is a reference.

The Haskell CI workflow is at `.github/workflows/` and the README describes the project as work in progress, with an invitation to contact the author with corrections, adjustments, comments, suggestions and additional ideas, and a request to use the issue tracker for requests.

What the repository does not have is a published package. There are no GitHub releases, and the description on the repository is a mouthful that tells you the subject rather than the deliverable: Lambda the ultimate Pattern Factory, FP, Haskell, Typeclassopedia versus Software Design Patterns. The topics make the same point, listing builder-pattern, category-theory, design-patterns, factory-pattern, function-composition, functional-languages, functor, functors, gof-patterns, haskell, iterator-pattern, monad, monad-transformers, monoids, pattern-language, reader-monad, strategy-pattern, traversable, typeclasses, typeclassopedia.

The licence is Apache-2.0, and the last push was on 2026-08-26.

Editorial conclusion

LtuPatternFactory fits a developer who knows the GoF patterns and wants to see what the same structure looks like in Haskell, because the essays are organised pairwise with code on both sides, and because the pairing often resolves the pattern into something the language already gives you. Skip it if you are looking for a library or a tool, since the repository holds a README and a Haskell source tree with no published package, and note that the author calls it work in progress and asks for corrections through the issue tracker. Before you read it as gospel, remember that the mapping is one person's interpretation rather than a standard, and that the essay is written from the position of someone whose first languages were Lisp, Scheme and ML and who moved to C++ and Java. The last push was on 2026-08-26 and the licence is Apache-2.0.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. thma/LtuPatternFactory on GitHub