[Haskell-cafe] Martin Odersky on "What's wrong with Monads"
alex.solla at gmail.com
Sun Jun 24 10:50:24 CEST 2012
On Sun, Jun 24, 2012 at 12:27 AM, Chris Dornan <chris at chrisdornan.com>wrote:
> * To move between functional and monadic code you have to completely
> rewrite the code procedurally -- its
> true and (IMHO) regrettable.
It's false. do-notation is completely optional. It merely makes it easier
to extract multiple values from monadic actions, instead of the basic "one
value per step" bind provides. Using join and (>>=) is just as easy as
do-notation, once you understand the idiom.
A monad is, first and foremost, a functor. You can get at the underlying
algebra while statically ensuring relevant properties, using its functorial
or applicative or monadic interfaces.
For example: consider a function that parses a string into a Foo. It will
have a type like
parseFoo :: String -> Maybe Foo
Should "useFoo" have the type
useFoo :: Maybe Foo -> Maybe Bar
useFoo :: Foo -> Bar?
The maybe functor/monad encapsulates the behavior of propagating
possible-undefinedness, so we are entirely justified in using its
functor/monad interface to simplify our types. There is no reason to
redundantly have to pattern match on (Just foo) or (Nothing) when we can
abstract the control structure away and do
useFoo <$> (parseFoo "Foo 1") -- (<$> == fmap)
(parseFoo "Foo 1") >>= return . useFoo
Expressing procedural code
> functionally is as unnatural and error
> prone as expressing functional code procedurally in my experience -- that
> Haskell avoids compelling the programmer to
> do either within its strongly-typed functional framework is (IMHO) its
> invention(*) and enduring strength.
Haskell didn't invent monads. They have been in use since Grothendieck's
work in algebraic topology. At least! It is not hard to make a plausible
case that the Pythagoreans had a theory of monads in mind 2500 years ago.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe