Ah... so the secret is in the hidden variables. On some level I am beginning to fear that Monads resurrect some of the scariest aspects of method overriding from my OO programming days. Do you (all) ever find that the ever changing nature of >>= makes code hard to read? On 4/15/07, jeff p wrote:

Hello,

On 4/15/07, David Powers wrote:

...

so... this is likely a question based on serious misunderstandings, but can anyone help me understand the exact mechanism by which monads enforce sequencing?

Monads do not enforce sequencing.

In general, data dependencies enforce sequencing (i.e. if expression x depends upon expression y then expression y will have to be evaluated first). Consider:

let x = case y of Just y' -> f y' Nothing -> g y = some code in more stuff

Here y must be evaluated before x because x needs to look at y in order to compute.

...

Specifically, I'm confused by the >> operator. If I understand things properly f a >> g expands to something like:

f >>= \_ -> g

What I'm missing is how the expansion of f is ever forced under lazy evaluation. Since the result is never used, doesn't it just stay as a completely unevaluated thunk?

(>>=) is an overloaded function. Some instances of it will cause f to be evaluated, others won't. Consider the State monad:

instance Monad (State s) where return a = State $ \s -> (a, s) m >>= k = State $ \s -> case runState m s of (a, s') -> runState (k a) s'

Note that (>>=) causes m to be evaluated (up to a pair) before evaluating k because (>>=) needs to look at the result of m.

An example of a monad in which (>>=) doesn't force evaluation of the first argument before the second is the Identity monad:

instance Monad Identity where return a = Identity a m >>= k = k (runIdentity m)

Note that (>>=) actually forces the evaluation of k before m.

-Jeff

Donald Bruce Stewart wrote:

david:

...

Ah... so the secret is in the hidden variables. On some level I am beginning to fear that Monads resurrect some of the scariest aspects of method overriding from my OO programming days. Do you (all) ever find that the ever changing nature of >>= makes code hard to read?

You always know which monad you're in though, since its in the type. And the scary monads aren't terribly common anyway.

Also, the monad laws impose a level of sanity that most OO frameworks do not, right?

Like point free notation, I worry about what somebody somewhere is doing to it.... :) The existence of a well understood community standard (add a type signature to your functions and only use monad operators with the laws) helps a lot - but both pieces are optional. I suppose the shorter and more declarative nature of Haskell functions makes it a less urgent point though. On 4/16/07, Donald Bruce Stewart wrote:

clifford.beshers:

...

Donald Bruce Stewart wrote:

david:

Ah... so the secret is in the hidden variables. On some level I am beginning to fear that Monads resurrect some of the scariest aspects of method overriding from my OO programming days. Do you (all) ever find that the ever changing nature of >>= makes code hard to read?

You always know which monad you're in though, since its in the type. And the scary monads aren't terribly common anyway.

Also, the monad laws impose a level of sanity that most OO frameworks do not, right?

Ah yes, and we have the 3 laws of monads. If you break these , the monad police will come and lock you up.

-- Don