Functional Discoveries in the Microsoft Sociocosm 02/20/2009

RickM — Fri, 20 Feb 2009 17:41:00 GMT

This week we have practical examples of Lazy Evaluation with Memoization, an interview with Don Syme and a discussion on the Visitor Pattern’s place in F#. Also, any comments on the new title for my weekly posting would be appreciated.

Forum – Memoization and Lazy Evaluation in F# on HubFS

In this thread brianmcm (Brian McNamara) and divisortheory (???) explore using memorization and LazyLists to optimize a Trial Division driven prime generator. It’s interesting to look at how their prime generator evolved over time as they incorporated these ideas and optimized.

Article – Kathryn Edwards interviews Don Syme on F# Development

In this technically light but still extremely interesting interview, Kathryn mainly directs the conversation in the direction of the development and adoption of the F# programming language. The most interesting thing I gleaned from the interview?

One of the key designers of Haskell, Simon Peyton-Jones, is just down the corridor from me at Microsoft Research Cambridge and has been a great help with F#.

Perhaps my F#/Haskell genealogy graph needs an additional arrow.

Blog – Stephen Easey’s (?) Visitor Patten in C# and F#

In this post Stephen explores the Visitor Patten in both C# and F#. I always love to see examples of how much more beautiful and concise F# is than C#. The 218 line C# implementation shown beside the same implementation in 64 lines of F# makes for a great comparison in this regard.

I agree with Stephen’s conclusion in that, given the purpose of the visitor pattern is to separate algorithm from object via a double dispatch layer, in many situations the visitor pattern is unnecessary in F# because of its advanced pattern matching capabilities.

However, I feel that he may not have considered the perspective of an API provider. In this context, it may be desirable for the consumer of an API to be able to extend the dispatch process to handle new cases. The issue with a single monolithic matching function is that all of the logic is contained within that single function and so the system is no longer nearly as open to extension. This violation of the Open Closed Principle (which applies to building APIs in any type of language) will make for difficult to reuse software.

Perhaps a F# pattern matching equivalent could be made with lambda functions for each branch. Lambdas could be curried into the matching function and so each branch could potentially be replaced with new logic by the consumer. However, this is feels to me like reimplementing OO with FP constructs.

Rick Minerich's Development Wonderland : csharp, lazy

Functional Discoveries in the Microsoft Sociocosm 02/20/2009

Forum – Memoization and Lazy Evaluation in F# on HubFS

Article – Kathryn Edwards interviews Don Syme on F# Development

Blog – Stephen Easey’s (?) Visitor Patten in C# and F#