Yet Another Monad Tutorial

[Wolfgang Jeltsch]

On Thursday, 2003-08-14, 13:37, CEST, blaat blaat wrote:
> [...]

Hello,

I don't know exactly which of the following questions have already been 
answered but I decided to answer them all anyway.

> What is the difference between putStr "a", (putStr "a", putStr "a"), putStr
> (putStr "a"), putStr (show (putStr "a"))?

As I stated earlier, IO a denotes an I/O action which has a result of type a. 
So the above expressions have the following meaning:
    putStr "a":
        an I/O action outputting the string "a"
    (putStr "a",putStr "a"):
        a pair of two I/O actions, both outputting the string "a" (This pair
        is not executable like an I/O actions is.)
    putStr (putStr "a"):
        illegal expression because the argument of putStr has to be of type
        String but putStr "a" has type IO ()
    putStr (show (putStr "a")):
        For this to work, IO () has to be an instance of class Show which
        roughly means it must be convertable into a string. putStr "a" is the
        I/O action which outputs "a" (see above). With a appropriate Show
        instance, show (putStr "a") would yield a string representation of
        this I/O action. putStr (show (putStr "a")) would be an I/O action
        which outputs this string representation.

> At the moment objects of type IO a _only_ get evaluted when they are the
> _sole_ result of a Haskell program.

I/O expressions get evaluated the same way every other expression does. But 
theit resulting I/O actions get *executed* only under a certain condition. 
And the condition is that the action in question has to be a part of the main 
I/O action.

Evaluating an expression of type IO a doesn't mean to execute it but to 
"calculate the I/O action". Since Haskell is pure, expression evaluation 
never does any I/O. I/O actions are not executed by expression evaluation but 
because the meaning of a Haskell program is to execute main.

> What kind of strange dichotomy is that? Is not the _only_ interpretation of
> this dichotomy that objects of type IO describe impure programs (composed of
> actions which are only evaluated when...)?

Yes, they *describe* impure programs. But as I just said, evaluating the 
actions doesn't mean to execute them.

> [...]

> And, if so, is not the only relation between a monad and doing functional IO
> that there is a monadic manner to construct descriptions of impure programs?
> If so, are there also non-monadic ways which might be equally interesting?

Yes, there is nothing magical about monads. They are just an abstract concept 
which fits nicely in the context of building descriptions of actions. And 
there are other ways of constructing such descriptions (as someone already 
mentioned).

> [...]

> > From: Derek Elkins <ddarius@hotpop.com>
> > To: "blaat blaat" <l4t3r@hotmail.com>, haskell-cafe@haskell.org

> > [...]

> > > I believe that central in the IO-issue is not the fact that we are using
> > > monads for IO - but that we can purely create impure programs which do
> > > the IO for us ;-), and that those do not have to be of the monadic kind.

Exactly.

> [...]

Wolfgang