[Haskell-cafe] Monad explanation

[Jonathan Cast]

On Thu, 2009-02-05 at 15:52 -0800, David Leimbach wrote:
> 
> 
> On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast
> <jonathanccast at fastmail.fm> wrote:
>         
>         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.
> 
> All Haskell programs start as 

> main :: IO ()

> though... so they all get evaluated in the context of another IO ()
> don't they?

Well...  Haskell compilers and runhaskell-style interpreters (not
regular Hugs/ghci!) take the value of Main.main as `the program'.  But
that feels (to me --- I could be wrong) like an aspect of a particular
hosted environment.  REPLs can handle programs that aren't wrapped up in
IO at all; and there's no reason why IO has to be the type of
IO-performning-things in REPLs, either.  You could just as well write a
REPL that took, say, tangible values [http://haskell.org/haskellwiki/TV]
as input instead, and displayed them.  So it's more a matter of Haskell
implementations can be given an IO value to run than that combining IO
values together somehow runs them.

jcc