+1 . I would love to read something that is the equivalent of 'design
patterns', but for functional languages.. I want to learn how to "think"
functionally.
If you want to learn how to "think" functionally, forget you ever
heard the words "design pattern". There shouldn't be patterns in your
programs. If there are, that means that either your language isn't
providing you with enough abstractions or that you aren't using the
abstractions that are available (or possibly both).
while that is perhaps the ideal, we often hit intermediate stages, where it
is useful to express the pattern of what we are trying to program, before
attempting to extend the language so that we can capture that pattern
more easily. and even if the pattern then becomes as trivial as "use
MonadPlus for multiple solutions" or "use combinators and language
recursion to capture grammars for parsers", it may still be useful to
list them, because that makes it easier to communicate them to others
(and would give newcomers a way in to making better use of the
abstractions that are available).
what is perhaps different in Haskell is that instead of managing growing
databases of complex patterns with arbitrary names, the language evolves
and generalizes existing features to make the common patterns easy to
capture. once that happens, the pattern description becomes short enough
and the language features become general enough to make invented names
superfluous, and listings of design patterns less necessary.
for many instances of that, and generally for nice-to-read Haskell, I
recommend browsing through Mark Jones' papers:
http://web.cecs.pdx.edu/~mpj/pubs.html
for starters, try the Springschool paper or the one on monad transformers.
Claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
