John Hughes wrote: > > > On Mon, 2 Dec 2002, Andrew J Bromage wrote: > > > > > ... If you mention a term like "design patterns", > > > > well I love design patterns, it's just that in Haskell-land > they are > > called higher-order functions, or polymorphic functions, etc. > > > > -- Johannes Waldmann ---- > http://www.informatik.uni-leipzig.de/~joe/ > > -- > > Or maybe > more general notions, such as > > "define a recursive datatype together with a catamorphism > combinator" > > or even > > "embed a domain-specific language via combinators over an ADT" > > There are patterns of that sort in our programs, which we > would probably rather call design techniques, which aren't so > easily captured by a higher-order function definition.
It seems like all the patterns, at least the ones in the GoF's enumeration, can be expressed as higher-order functions and classes if we only would have a way to traverse a record structure dynamically. If someone can think of a "design pattern" (such as one from the GoF book) which is not expressible directly in Haskell, up to data type structure (i.e., assuming the structure to be list or a fixed tree structure...), please let us know. Till then, we "Haskellers" will probably continue expressing our patterns either directly in Haskell or using highly formal language, with terms such as "catamorphisms". The virtue, and weakness, of traditional design patterns is their vagueness and informal character, making them (1) comprehensible to the 90% of the developer community not familiar with category theory but (2) constituting only vague schemes for implementation; in fact, they are often so vague that it takes quite some effort to determine whether a fragment of code follows a pattern. Actually, showing a fragment of code to a group of software enginers and having them pick the pattern embodied will probably lead to differing opinions. In Haskell-land, or in any other land on the Functional continent, a catamorphism is a catamorphism: as soon as an engineer recognizes the algorithm of a code fragment, he will immediately determine the catamorphic (or any other <X>morhpic) character. No fuss, no differing opinions. Ah, this is my land... /David _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
