<br><br><div class="gmail_quote">On Wed, Sep 22, 2010 at 5:20 AM, Johannes Waldmann <span dir="ltr"><<a href="mailto:waldmann@imn.htwk-leipzig.de">waldmann@imn.htwk-leipzig.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
> - are there any prior art in documenting idioms and patterns in FP [...]<br>
<br>
you got this backwards: what some folks call "idioms and (design) patterns"<br>
actually *is* FP, because it is just this: higher order functions.<br>
And it's been there some decades (lambda calculus).<br>
That also explains the absence of any Design Patterns/Gang-of-Four<br>
kind of book for Haskell - it's just not needed.<br>
(as you say, map and fold are your patterns.)<br>
<br>
Best - J.W.<br></blockquote><div><br>Most developers misunderstand the Gang of Four design patterns, including the authors. For example, the GoF State Pattern is described synchronously, but anyone who has thought about this is in deep detail, e.g. actor theory, knows that asynchronous transitions are possible and that the target state can be decoupled from the source state. In mathematics, the most basic way to understand this is through finite state automata, since an automaton is only dependent on its current state and input to determine the next transition. GoF confuses the issue by insistenting on synchronous communication between classes that represent states. GoF has subpar explanations, but please separate the intellectual wheat from the chaff.<br>
<br>I have also heard some argue that GoF patterns all have the same structure. This is not true. I've heard confused programmers say that the Proxy pattern and the Decorator pattern "look the same". Decorators provide structural support of nesting and Proxies do not, but the key difference between the two is that a Decorator is about adding or removing properties *dynamically*, whereas a Proxy is about accessing existing properties through a known static structure. How does higher order (recursive) functions make such patterns obsolete?<br>
</div></div><br>Some existing design patterns are applicable regardless of paradigm, and will continuosly get re-invented until people learn better and start to realize how general the patterns are.<br><br>Example: Deterministic systems are easier to debug than non-deterministic systems, due to the fact non-deterministic systems cannot generalize the Kahn Principle (this is known as the Brock-Ackerman Anomaly). Ergo, one of the best things you can do as a programmer is isolate nondeterminism. Patterns for doing so have been known for decades in the embedded systems community, and go by names such as Processor-Actuator, Watchdog, etc. I've suggested to some interested in FRP research that they'd be wise to look at those patterns, not as competitors but as complementary material to enhance every student's ability to inhale the FRP approach. Otherwise you end up with an engineering discussion that is more focused on the cute details on FRP and not how to design good systems!<br>
<br>Currently the functional programming research community seems very aware of GoF design patterns but completely unaware and/or uninterested by real-time design patterns. I predict this will change within the next 5 years.<br>
<br>Luc Taesch,<br><br>Probably my favorite book on the subject is Thomas Kuehne's Ph.D. thesis which went out of print within the last year, but is freely available from the author's page: <a href="http://c2.com/cgi/wiki?FunctionalPatternSystemForObjectOrientedDesign">http://c2.com/cgi/wiki?FunctionalPatternSystemForObjectOrientedDesign</a><br>
<br>One of the patterns Kuehne discusses, Transfold, is something every computer scientist should understand.<br><br>Unfortunately, the book uses the Eiffel language and not a functional language. However, the author brings up good points that transcend what language is being used for implementation. Also, since it is a book, it is more coherent than reading many papers on object-functional patterns.<br>
<br>If you don't use Haskell in your day job (like me), then you might use a more conventional language like C#. If that is the case, then papers by Jeremy Gibbons will likely also be right up your alley (they will likely help you better communicate ideas to your coworkers). He has written a number of very readable papers about datatype generic programming. <a href="http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/">http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/</a><br>
<br>+1 to the idea of a book on patterns in a functional language.<br><br>Cheers,<br>Z-Bo<br>