Re: Design patterns in Haskell
I spent an awful lot of time doing a brain-dump into these pages and am a bit dissapointed that they seemed to have dissappeared without trace. Were these archived anywhere Yes, they are in fact still there (they are all in RCS). The problem is, the Wiki is broken. I'm going to try and restore the pages statically for the moment (i.e., non-editable), and then look at how to make them work properly. Assistance welcome! --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
I spent an awful lot of time doing a brain-dump into these pages and am a bit dissapointed that they seemed to have dissappeared without trace. Were these archived anywhere Keith Wansbrough [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 03/12/2002 18:02 To:matt hellige [EMAIL PROTECTED] cc:[EMAIL PROTECTED], (bcc: Chris Angus/Lawson) Subject:Re: Design patterns in Haskell size. while there's really no substitute for experience, i really believe we could benefit from some patterns. There was a list of design patterns for Haskell on the Wiki (back in the days when it worked): http://haskell.org/wiki/wiki?CommonHaskellIdioms --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
[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
Re: Design patterns in Haskell
size. while there's really no substitute for experience, i really believe we could benefit from some patterns. There was a list of design patterns for Haskell on the Wiki (back in the days when it worked): http://haskell.org/wiki/wiki?CommonHaskellIdioms --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Design patterns in Haskell
I shamelessly copy from the abstract of [1]:
We contend that design patterns can be an effective means of
consolidating and communicating program construction expertise for
functional programming just as they have proven to be in
object-oriented programming. One might suppose that the powerful
abstraction mechanisms of functional programming obviate the need for
design patterns, since many pieces of program construction knowledge
can be captured by reusable functions. This confusion of design
patterns with reusable components misses the point: patterns start
where components end, in the sense that the former describe how the
latter can be constructed and used. Thus, additional abstraction
\emph{creates} the need for new design patterns.
[1] Design Patterns for Functional Strategic Programming
http://www.cs.vu.nl/Strafunski/dp-sf/
Ralf
P.S.: Should we move to haskell-cafe@... ?
--
Ralf Laemmel
VU CWI, Amsterdam, The Netherlands
http://www.cs.vu.nl/~ralf/
http://www.cwi.nl/~ralf/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
