[Haskell-cafe] Re: Re: Explaining monads

[Benjamin Franksen]

Brandon S. Allbery KF8NH wrote:
> On Aug 13, 2007, at 16:29 , Benjamin Franksen wrote:
>> 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.
> 
> Clearly it does, but not as a side effect of the *monad*.  It's  
> ordinary Haskell data dependencies at work here, not some mystical  
> behavior of a monad.

I can't remember claiming that Monads have any mystic abilities. In fact,
these Monads are implemented in such a way that their definition /employs/
data dependencies to enforce a certain sequencing of effects. I think that
is exactly the point, isn't it?

>> What about State? The effect is reading/writing the state. Again,  
>> the State
>> Monad takes care that these effects get sequenced, and again that's  
>> what
>> you expect it to do for you.
> 
> No, I expect it to carry a value around for me.  If I carry that  
> value around myself instead of relying on the monad to do it for me,  
> *the calculation still gets sequenced by the data dependencies*.

Of course, you can unfold (itso inline) bind and return (or never use them
in the first place). Again, nobody claimed Monads do the sequencing by
employing Mystic Force (tm); almost all Monads can be implemented in plain
Haskell, nevertheless they sequence certain effects -- You Could Have
Invented Them Monads Yourself ;-)

The Monad merely captures the idiom, abstracts it and ideally implements it
in a library for your convenience and for the benefit of those trying to
understand what your code is supposed to achieve. She reads 'StateM ...'
and immediately sees 'ah, there he wants to use some data threaded along
for reading and writing'.

Cheers
Ben