Design patterns in Haskell

[Frank Atanassow]

Andrew J Bromage wrote (on 03-12-02 09:52 +1100):
> On Mon, Dec 02, 2002 at 08:26:06AM +0100, Johannes Waldmann wrote:
> 
> > well I love design patterns, it's just that in Haskell-land 
> > they are called higher-order functions, or polymorphic functions, etc.
> 
> Can I safely translate that as "We use design patterns but we don't
> like the name?"
> 
> In a different language, you use different design patterns.  Just as
> iterator-based patterns are next to useless in Haskell (where we have
> lazy streams), patterns based on CPS are next to useless in a
> language with state and non-local return constructions.

I think there is a world of difference between GoF-style design patterns and
things like HOFs, polymorphism and whatnot in Haskell.

If you are programming GUI applications in C and use callbacks for the widget
actions, then you are basically using the design pattern which gets formalized
as HOFs in an ML-like language. But C will not guarantee for you that you
callback function is well-typed, hold onto the data in the closure, do the
necessary garbage collection, etc. Those things may seem like details, but
they are what make HOFs robust and practical to use ubiquitously; the callback
design pattern, since it is basically puts the burden on the programmer, can
never hope to achieve that degree of robustness.

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.

-- 
Frank