Yet Another Monad Tutorial
Tue, 26 Aug 2003 19:55:30 +0200
On Thursday, 2003-08-14, 13:37, CEST, blaat blaat wrote:
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:
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
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
> > From: Derek Elkins <firstname.lastname@example.org>
> > To: "blaat blaat" <email@example.com>, firstname.lastname@example.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.