Functional Design Patterns

[Jon Harrop]

As F# grows in popularity, an increasing number of C++ and C# developers are
asking about design patterns in ML. To me, this has two separate meanings:

. The (re)implementation of established design patterns from OOP in ML.

. The description of recurring patterns found in idiomatic ML code.

I find the latter much more interesting and would like to know what design
patterns, if any, people have noticed in functional code in general.

Off the top of my head, I can think of:

. Continuation passing style.

. Monadic style.

. Combinators, e.g. parser combinators.

. Use of extra accumulator arguments when transforming into tail recursive
form.

. Parallel pattern matching to amortize deconstruction.

. Phantom types.

. Data structure (e.g. term) rewriting.

. Untying the recursive knot.

. Workarounds for polymorphic recursion.

. Solutions to the expression problem.

. Manual lambda-lifting to avoid unnecessary closures in OCaml. Manual
lambda-unlifting to exploit branches in F#.

. Representation of symbolic expressions and abstract syntax trees.

. Dynamically-typed interfaces.

Can you think of any others?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u

[German-Andres Delbianco]

The following might not contribute directly to the topic. But....

Jeremy Gibbons : "Design Patterns as Higher-Order Datatype-Generic
Programs "

http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/hodgp.pdf

Just to bring a pure approach on the table. :)

[guthrie]

On Jul 11, 4:49 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> As F# grows in popularity, an increasing number of C++ and C# developers are
> asking about design patterns in ML. To me, this has two separate meanings:
>
> . The (re)implementation of established design patterns from OOP in ML.
>
> . The description of recurring patterns found in idiomatic ML code.
>
> I find the latter much more interesting and would like to know what design
> patterns, if any, people have noticed in functional code in general.
>

-- I think that in general most of these would be idioms of the
language (or paradigm), not design patterns.

To be a design pattern they would have a specific context, problem,
structure, etc. (per GOF).

So using combinators for parsing, or the polymorphic recursion work-
around, and accumulator arguments to solve specific problem, would all
be design patterns.

CPS wouldn't be a pattern I don't think; until applied to solve a
particular problem (it might applied in several problem solutions, and
thus form several distinct patterns).