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 <[EMAIL PROTECTED]> wrote:
Hello, On 4/15/07, David Powers <[EMAIL PROTECTED]> 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe