[Haskell-cafe] Re: Explaining monads

[Derek Elkins]

On Mon, 2007-08-13 at 22:29 +0200, Benjamin Franksen wrote:
> Brian Brunswick wrote:
> > One thing that I keep seeing people say (not you), is that
> monads /sequence/
> > side effects. This is wrong, or at
> > least a limited picture.
> > 
> > /All/ of the above structures are about combining compatible things things
> > together in a row.
> > /None/ of them force any particular order of evaluation - that all comes
> > from the particular instance. So its
> > only a particular feature of IO that it sequences the side effects. Others
> > don't - we can have a lazy State
> > monad that just builds up big thunks.
> 
> I am a bit astonished.
> 
> Let's take the simplest example: Maybe. The effect in question is the
> premature abortion of a computation (when Nothing is returned). And of
> course Maybe sequences these effects, that's what you use it for: the
> _first_ action to be encountered that returns Nothing aborts the
> computation. Clearly sequencing goes on here.

You are wrong. Proof: Let's take a simpler example: Identity.  QED
This also disproves David Roundy's statement that 
do x <- return 2; undefined; return (x*x) will hit bottom.

Reader also does not sequence it's "actions".  Writer is a kind of funny
example.

Certainly, any monad instance where (>>=) needs it's first argument to
determine whether to continue, e.g. Maybe, Either, IO, Parser, Cont,
List, Tree will clearly need to force it's first argument before
continuing, but that's just the nature of the situation.