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.