[Frank Atanassow <[EMAIL PROTECTED]>] > > 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 [EMAIL PROTECTED] http://matt.immute.net _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell