Design patterns in Haskell

[matt hellige]

[Frank Atanassow <franka@cs.uu.nl>]
> 
> Furthermore, design patterns come with a set of informal hints about when and
> where to apply the pattern. The notion of HOF is, of course, completely
> neutral about this, except insofar as the type system forces you to provide a
> HOF where a function is expected. OTOH, the advice that "you should use HOFs
> to model widget actions" or "you should use HOFs to allow customization of
> applications via hooks" (as in Emacs LISP) could reasonably be construed as a
> design pattern. So maybe a design pattern can be regarded as a correspondence
> between formal concepts and domain-specific ones.
> 

i think this (especially the last sentence) is a crucial observation.
all too often, the fp community (communities) seems to write design
patterns off on the grounds that "our languages do that stuff for us".

this is based on far too unsophisticated an understanding of design
patterns. certainly the patterns that are useful in c++ will not all
be useful in haskell, and many of them will even appear trivial. but
this does not mean that the appropriate correspondence(s) "between
formal concepts and domain-specific ones" will always be obvious. in
fact, this is exactly the kind of information that programmers new to
haskell need more of.

one of the purposes of design patterns is to capture the idiom of a
particular language, often using fairly specific domain examples. "to
solve this kind of problem in this language, these are the usual
techniques. here are guidelines for choosing between them..." these
guidelines often include, for example, which techniques work well (or
poorly) with which others, some counter-indications for using a
particular technique, which techniques excel in particular
circmstances ("pattern A is a better choice when you expect to
register callbacks only once and use them many times, while B is a
better choice when you expect callbacks to change quite frequently"),
etc.

i hope it's obvious that this is significantly more information, and
significantly more useful, than: "when you need something like
callbacks, use hofs." i know i'm not the only programmer who
understands most of the syntax and semantics of haskell, but still
feels far less than confident engineering a program of any decent
size. while there's really no substitute for experience, i really
believe we could benefit from some patterns.

m

-- 
matt hellige                  matt@immute.net
http://matt.immute.net