[Haskell-cafe] Re: Re: Explaining monads

[Benjamin Franksen]

Derek Elkins wrote:
> 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

I don't accept this proof. Note the wording: 'Monads sequence (certain,
monad specific) effects'. Identity has no effects, ergo no sequencing has
to happen. I didn't claim that /all/ monadic actions are (necessarily)
sequenced.

> 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". 

Ok, I admit defeat now ;-) Monads in general /allow/ sequencing of (certain)
effects, but it is not necessary for a monad to do so.

> Writer is a kind of funny example.

In which way?

> 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.

Don't forget State, clearly it sequences actions even though it always
continues; but maybe 'sequencing' is too strong a word: Just as with
Reader, a sequence of reads (with no writes in between) may actually happen
in any order, State imposes strict order on groups of adjacent reads and
all (single) writes, correct?

Ok, I think I understand where I was misled: I took the means for the end.

There are many monads that impose a certain order on (some) effects; but
this is done only as far as necessary to maintain X, whatever X may be,
maybe X is just the monad laws?

What about: The imperative way always imposes a sequencing of actions,
period. Monads in Haskell (except IO which is just imperative programming)
allow us to impose ordering on effects only partially, ideally only where
necessary.

Thanks for further enlightening me.

Hey, I just said that sequencing is a means, not an end, but maybe even this
is not necessarily true. I imagine a 'Sequence Monad' whose only effect
would be to order evaluation... would that be possible? Or useful?

Cheers
Ben