Here my attempt to match up design patterns with functional programming constructions:
Chain of responsibility
Fold request across the chain of handlers, at each step returning either (using Either type) request to continue fold (possibly with transformed request), or returning handled request indicating that fold is finished.
Command
Request is held in data (e.g. as discriminant union)
Interpreter
Language is available as typed data structure (e.g. discriminant union) and is interpretable with functions calls.
Alternative:Language is defined in monadic form (e.g. as function calls) and is interpreted as part of the monad's interpretation.
Iterator
Exposed traversal functions hide data structure of containers. Functions typically work on zipper focus adapted to the containers structure.
Mediator
Exposed functions stay at top/root of exposed data structures.
Memento
Use immutability and exposure of intermediate states to allow recovery, restart or alternate computation from previous intermediate states.
Observer
Associate container of data with container of queries (e.g filter plus callbacks). Changes to data container (insert, update, removal) triggers matching query callbacks, change to queries may trigger callbacks. Callbacks are either in a monadic structure or pass around a state context.
State
Data context position is indexed (e.g. by one or more keys), associated state is stored in corresponding state monad where individual states are found with index.
Strategy
Single function signature implemented in multiple ways.
Template Method
Use type classes to refine implementation by type variant.
Visitor
Break down algorithm into sub-functions; Provide these sub-functions in argument to algo; Use them within algo; Provide different ones if you want to change behavior of algo.
Adapter
Adapter functions that takes one or more functions with given signatures and returns one or more functions with adapted functions.
Bridge
Clients accesses a bridge data type that holds functions.
Composite
Use recursive data types.
Decorator
Data has a dynamic map of functional operators.
Facade
API presents no internal types and is as "flat" as possible. This may mean that certain functional constructions have been "collapsed" into a purely data centric view in order to limit the "depth" of the API.
Flyweight
Flyweight data structure are often provided as "first" arguments of functions. These functions can then curry their first argument so that the flyweight shared data is provided but does not need to be "passed around" everywhere.
Proxy
Data type that "hides" another type. Possibly relies on using an index/key reference and a map like container to store original data.
Abstract Factory
Factory hides the finer type of created data and functions. Losing the inner type can be tricky because the exposed signatures must still need to be powerful enough to do everything you want with the exposed API (as we assume that no dynamic type casting is allowed). This may mean that you need powerful type features to make the abstract factory concept work (e.g. GADT).
Builder
Define functions to construct data. This is in fact the "normal" way to write functional style.
Factory Method
Use polymorphism, types are determined by inner types of arguments.
Prototype
(Immutable data does not need to be copied).
Singleton
Encapsulate the access to the singleton as a mutable variable within a function; Use this function to access singleton. In immutable setting, store singleton within a state monad.
(I'll revisit this one if I have the time to try to put side by side an OO definition of the pattern with a functional definition of design pattern. Also it is a bit minimalistic).
All original content copyright James Litsios, 2013.