+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