[Haskell-cafe] Explaining monads

[Lanny Ripple]

Look!  You are doing it again!  :)  Does that paragraph even 
contain the word "Monad"?  :)

I'm aware a monad is an abstraction and as such it doesn't *do* 
anything.  My point was along the lines that you don't need to 
know that your working in a field to be able to learn that

    3/2 = 1.5

.

   -ljr

Jeff Polakow wrote:
> 
> Hello,
> 
> There is clearly a problem with the Haskell/monad tutorials out there...
> 
>  > The tutorials seriously need to step back and start with
>  > something like, "To enforce order of evaluation we evaluate
>  > closures* returning a defined type.  The first closure will feed
>  > its result to the second which will in turn feed it's result to
>  > the third.  Since the third closure can't be evaluated without
>  > having the results from the second and first (and thus they had
>  > to be evaluated earlier in time) we get a defined evaluation
>  > sequence.  Here are some examples..."
>  >
> The style of this description is nice; however the description itself is 
> wrong.
> 
> Monads DO NOT determine order of evaluation. Previous posts on this 
> thread give several examples.
> 
> In lazy languages, data dependencies determine the order of evaluation. 
> X must be evaluated before Y if Y depends upon the result of X. You can 
> force the order of evaluation without using a monad just as you can have 
> a monad which does not determine the order in which things get evaluated.
> 
>  From the point of view of a programmer, a monad is simply a useful 
> (higher-order) combinator pattern. All monadic code can be flattened by 
> replacing occurrences of bind (>>=) with it's definition.
> 
> One general intuition about monads is that they represent computations 
> rather than simple (already computed) values:
> 
>     x :: Int               -- x is an Int
> 
>     x :: Monad m => m Int  -- x is a computation of an Int
> 
>     x :: [Int]             -- x is a computation of an Int which can 
> return multiplie values
> 
>     x :: Maybe Int         -- x is a computation of an Int which might 
> fail (return Nothing)
> 
>     x :: State s Int       -- x is a computation of an Int which relies 
> on, and returns (possibly modified)
>                            --   a value of type s. Note: State s Int is 
> isomorphic to: s -> (Int,s)
> 
>     x :: IO Int            -- x is a computation of an Int which can 
> interact with the outside world.
> 
> Return explains how to make a simple computation which returns a 
> specified value.
> Bind explains how to use the result of a computation to compute 
> something else.
>  
> -Jeff
> 
> ---
> 
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.

-- 
Lanny Ripple <lanny at cisco.com>
ScmDB / Cisco Systems, Inc.