Re: [Haskell-cafe] Design Patterns by Gamma or equivalent
2009/3/11 Mark Spezzano
I’m very familiar with the concept of Design Patterns for OOP in Java and C++. They’re basically a way of fitting components of a program so that objects/classes fit together nicely like Lego blocks and it’s useful because it also provides a common “language” to talk about concepts, like Abstract Factory, or an Observer to other programmers. In this way one programmer can instantly get a feel what another programmer is talking about even though the concepts are fundamentally abstract.
Because Haskell is not OO, it is functional, I was wondering if there is some kind of analogous “design pattern”/”template” type concept that describe commonly used functions that can be “factored out” in a general sense to provide the same kind of usefulness that Design Patterns do for OOP. Basically I’m asking if there are any kinds of “common denominator” function compositions that are used again and again to solve problems. If so, what are they called?
You might find it useful to read the original works upon which the whole "design pattern" economy is based, namely Christopher Alexander's books (http://www.patternlanguage.com/leveltwo/booksframe.htm?/leveltwo/../bookstor...). I liked "Notes on the Synthesis of Form", which predates his pattern language stuff. My $0.02: design patterns became popular in the imperative language community precisely because such languages lack the formal discipline of functional languages. Alexander came up with the notion of a pattern language in order to bring some kind of discipline and abstraction to observed regularities in architecture, urban design, etc. By definition such a language cannot have anything close to formal semantics, any more than a natural language lexicon can have formal semantics. Alexander's writing is very interesting and thought provoking, but I'm not sure it has much to offer the world of functional programming. Programmers used Alexander's ideas to try to bring some order to both specifications and programs. A pattern language is a natural for trying to describe a real-world problem one is trying to solve. Imperative programmers also used it to describe programming patterns. Implementations of things like Observer/VIsitor etc. are ad-hoc, informal constructions; the equivalent in a functional language is a mathematical structure (feel free to fix my terminology). I don't think one needs design patterns for Haskell; it has mathematics and more-or-less formal semantics. Who needs "Visitor" when you have "For All"? Although design patterns may still be useful for describing a real-world problems I suspect one would be better off dumping the notion of design pattern, the better to avoid cognitive dissonance when trying to think in purely functional terms. Cheers, -gregg
Because Haskell is not OO, it is functional, I was wondering if there is some kind of analogous "design pattern"/"template" type concept that describe commonly used functions that can be "factored out" in a general sense to provide the same kind of usefulness that Design Patterns do for OOP. Basically I'm asking if there are any kinds of "common denominator" function compositions that are used again and again to solve problems. If so, what are they called?
Not about Haskell, but Peter Norvig has a presentation about patterns in more-or-less functional languages: http://norvig.com/design-patterns/ Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
Gregg Reynolds wrote:
Imperative programmers also used it to describe programming patterns. Implementations of things like Observer/VIsitor etc. are ad-hoc, informal constructions; the equivalent in a functional language is a mathematical structure (feel free to fix my terminology). I don't think one needs design patterns for Haskell; it has mathematics and more-or-less formal semantics. Who needs "Visitor" when you have "For All"?
In broad strokes I agree with the thesis, but this example is precisely one where functional languages run into the same issues as OO languages. The Visitor pattern is obviated in functional languages if and only if you construct your recursive types as a fixed-point on a functor representing the open recursive form of your type. Given this you can invoke category-extras or similar libraries[1] to tie everything together for you. Otherwise you end up writing boilerplate functions which are groundings of cata and other recursion schemes. In the Visitor pattern the visitor itself is your F-algebra, and each subtype of \mu F defines its piece of cata (in order to reflect the algebra back on itself and to tell it where to recurse). The algebra has to be written no matter what, since it's the one that does the real work. With category-extras you can define a single implementation of cata which works for all F; without it you write boilerplate groundings of cata for your specific F, exactly as in the Visitor pattern. With a sufficiently expressive reflection system in OO you can do the same CT trick and use introspection to determine the pieces of cata. The functional CT version is generally cleaner, more efficient, and safer, but it still requires taking the steps toward CT as a templating language since functional programming by itself doesn't obviate the Visitor problem. [1] Similar to OO reflection, you could instead use Template Haskell to crack open fixed-recursion types into their open-recursion variants and generate an instance of some Cata class, but once more it's the same trick all over again. -- Live well, ~wren
participants (3)
-
Bayley, Alistair -
Gregg Reynolds -
wren ng thornton