Re: [Haskell-cafe] Re: capture of idioms and patterns

G'day all.

Quoting Johannes Waldmann :

...

you got this backwards: what some folks call "idioms and (design) patterns" actually *is* FP, because it is just this: higher order functions. And it's been there some decades (lambda calculus). That also explains the absence of any Design Patterns/Gang-of-Four kind of book for Haskell - it's just not needed.

Err... no.

The phrase "design patterns" is a shorthand for "vocabulary of engineering experience". Zippers, continuation passing style, Church encoding... these are not what FP "is", but they are specific techniques that engineers working in Haskell need to know to use the language effectively.

... An often-overlooked bit of trivia is that the first books on design

There is no GoF-like book for Haskell because it's not an idea that needs promoting in printed form. We just point people to the wiki.

Cheers, Andrew Bromage ______________________________________________ I think a "functional design-pattern" section on the Haskell wiki would be a good idea. I think the "patterns" framework is a good and useful one, if we can communicate properly what design patters are and how

ajb@spamcop.net wrote: patters were not in computer science, but rather architecture. I would recommend "A Pattern Language: Towns, Buildings, Construction" and "A Timeless Way of Building" by Christopher Alexander to anyone who is interested in a great example of how design patterns are supposed to work (or anyone interested in constructing an attractive and functional building). I've never read GoF (it seemed a bit too focused on object-oriented design for my tastes), so I don't know how closely it follows Alexander's conventions. "A Pattern Language" is essentially a compilation of a couple hundred patterns -- a great resource if you want to build a house, but it doesn't offer much insight into what a pattern is. "A Timeless Way of Building", on the other hand, describes what a pattern is and how to go about discovering, documenting, and organizing (and, often, discarding) them. I was initially skeptical of "patterns", as they seemed like a rather vague concept, but it's actually quite formal. A pattern consists of some context in which the pattern can apply, a conflict that arises within that context, and a satisfactory solution to that conflict. Described this way, a pattern is an idea that makes itself a target for criticism, because a detractor can point out that the given pattern doesn't apply to its context, or that it doesn't resolve the conflict, or there may be some other pattern that works in a broader context that fully covers the narrow context. However, this makes it much easier to distinguish good ideas from bad ones. One notion about patterns that I'm not sure whether the GoF authors were aware of, is that the patterns can be arranged into a directed graph, where the most general patters form a sort of root, and the more specific, narrow patterns form the leaves. (Ideally, you would have a tree, but you might not.) A common problem whether designing buildings or programs, is that you get halfway into the design and have to start over because you come across some constraint that can't be circumvented. By starting with the most general patterns and working down to the more specific ones, you can reduce the amount of backtracking you will have to do. they're supposed to work. I think a lot of the basic knowledge about functional programming patterns is already there, it just needs to be formatted properly. Do people think this is the right way to document the Haskell community's "oral tradition"? -jim