Functional design patterns (was: How to get functional software engineering experience?)

[Ralf Lämmel]

--- Joe English <jenglish@flightlab.com> wrote

> ... there are plenty of FP design patterns
> in common use, it's just that FP'ers don't usually use the term
> "design patterns" to describe them.  I'm thinking of things
> like catamorphisms, anamorphisms (aka folds/unfolds), monads
> and functors, "the zipper", and of course the various catalogues
> of polytypic routines.

Almost agreed.
But, I adhere to an extreme and pragmatic point of view here:

 A design pattern is only real if it is part of design pattern 
 catalogue which in turn is formatted in a structured manner.
 IMO, it is misleading to confuse APIs, libraries, frameworks,
 catalogues of whatever routines with design patterns. 

I completely agree that all of the cited notions are worth
design patterns. But I don't like to confuse notions such as
this or that morphism, strictness annotation, monad transformation,
modular programming, reactive programming or polytypic programming
with the related design patterns I would like to see.

To give a simple example, think of parser combinators.
Does the mere combinator library of parsing combinators tell me
how to write parsers? Not really! What are the patterns here?
Here are few clumsy names:

- Deal with a priority
- Handle left recursion
- Enforce non-nested notation
- Separate out reusable syntax schemes
- Use this or that naming convention
- Integrate lexer
- Integrate pre-processor
- Define abstract syntax
- Handle semantics-directed constructs
- ...


> That's the main difference between FP patterns and OO patterns.
> OO patterns tend to be informal, intuitive guidelines; and
> though some FP patterns are like this (e.g., "combinator library",
> "embedded domain-specific language"), the majority can be
> described rigorously.  This gives them an added usefulness --
> you can actually "calculate" with them.

Yes, that's nice, and we should be able to use that to the
advantage of FP but this does not imply that all the other
ingredients of a design pattern (tradeoffs, alternatives, ...),
and the general format are not needed to claim a design pattern.

Ralf



=====
Dr. Ralf Laemmel
CWI & VU Amsterdam
http://www.cwi.nl/~ralf
ralf@cwi.nl

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com