Functional Design Patterns
Recorded at:
Re: Educational and entertaining
by
Nat Pryce
Unfortunately the functional programming community do not come up with as communicative pattern names as the object-oriented programming community!
Re: Educational and entertaining
by
Faisal Waris
Language support seems to be required to effectively work with monads - at least for statically typed languages.
For example, F#, C# (LINQ) have language support for monads. I have limited familiarity with Haskell but that also provides native support for monads.
I confess that even after using mondads (primarily as F# async{} monads and C# LINQ) I am still fuzzy. I have not had the 'aha' moment yet - even though I understand the mechanics of monad construction, the monadic 'laws' and such.
It just seems that coding becomes magically easier with monads. When/how to create that magic myself is where I lack.
Re: Educational and entertaining
by
Sadek Drobi
Patterns are about encoding featured, monads are about abstraction of plumping code.
Re: Educational and entertaining
by
Faisal Waris
In my case I have a monad implementation to manage COM object references. I am pulling data from Excel into F# for an optimization problem. Excel interaction is via COM. COM requires that if you acquire an object reference then you have to eventually release it. My code was getting messy managing COM object references. Now with a monad managing object references the code ends up being a lot cleaner.
Re: Educational and entertaining
by
Nat Pryce
Individual monad types are, as you say, implementations.
But the *concept* of a monad type, why you would want one, what they give you, what constraints they impose: that's a pattern.
Re: Educational and entertaining
by
Sadek Drobi
Please don't call monads patterns. THEY ARE NOT
functional patterns
by
Chris Angus
www.haskell.org/wikisnapshot/CommonHaskellIdiom...
This is a list of common idioms or patterns in Haskell which includes memoization
www.haskell.org/wikisnapshot/MemoisingCafs.html
Re: functional patterns
by
Faisal Waris
a) Design patterns in the GoF sense are meant to be implemented as part of your main application code.
Note the underlying assumption is that the above technique will work for most languages. The point of this presentation is that functional languages are expressive enough such that you can create pattern abstractions that can live separate from your main application code.
b) Monads are implementations that your main code would just use and such are not design patterns in the GoF sense
c) Putting together a monad implementation requires some method (and madness) and as such can be considered a pattern... but at a different level than GoF patterns.
Re: functional patterns
by
Jaime Metcher
Nowhere did I hear her say anything about monads being patterns or otherwise - I've no idea why you guys latched on to that.




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think