[Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote:
> 
> 
> On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast
> <jonathanccast at fastmail.fm> wrote:
>         
>         On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote:
>         >
>         >
>         > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner
>         > <wagner.andrew at gmail.com> wrote:
>         >                         I think the point of the Monad is
>         that it
>         >                         works as a container of stuff, that
>         still
>         >                         allows mathematically pure things to
>         happen,
>         >                         while possibly having some opaque
>         "other
>         >                         stuff" going on.
>         
>         >          This at least sounds, very wrong, even if it's not.
>         Monads
>         >         are not impure. IO is, but it's only _one_ instance
>         of Monad.
>         >         All others, as far as I know, are pure. It's just
>         that the
>         >         bind operation allows you to hide the stuff you
>         don't want to
>         >         have to worry about, that should happen every time
>         you compose
>         >         two monadic actions.

>         > Well all I can tell you is that I can have (IO Int) in a
>         function as a
>         > return, and the function is not idempotent in terms of the
>         "stuff"
>         > inside IO being the same.
>         
>         
>         Sure it's the same.
>         
>         >  cmp /bin/cat /bin/cat
>         > cp /bin/cat ~
>         > cmp /bin/cat ~/cat
>         >
>         
>         Pretty much the same, anyway.

> So if IO represents a program that when executed interacts with the
> world's state, is it safe to say that when I return (State Int Int),
> that I'm returning a "State program"?

I won't object to it.  Othe people might, though.

> That'd make sense as it really does look like we force the State to be
> evaluated with runState, evalState or execState.

> The only difference with IO then is that to get IO programs to run,
> you have to do it inside another IO program.

Meh.  Combining IO sub-programs into larger programs doesn't really `get
them to run'.  Better to say that an IO value is meaningful only to the
computer, and not mathematically (denotationally) useful.

jcc