Yet Another Monad Tutorial

[Lars Lundgren]

On Thu, 14 Aug 2003, blaat blaat wrote:

> 
> To many questions, not enough mail. First, thanks for all your replies. 
> Second, I stand totally corrected on the fact that we cannot break down 
> monads. Functions of type m a->b are called impure,

Haskell is a pure language, so there are *no* impure functions.
Expressions in haskell are also referentially transparent, except... there
are a few extensions that allow one to disguise a (possibly)
side-effect-full expression into one that haskell believes is RT (FFI or
unsafePerformIO comes to mind). This is really unsafe, since haskell might
evaluate it (which cause execution) any number of times including Zero and
One Zillion. The by newbies often requested IO a -> a extraction
function is a bad idea for this reason, and generally just means that the 
newbie has not understood how to deal with actions in haskell.

It is common for Monads to have a runme function of type
runme :: Monad m => m a -> a

Nothing strange about that.

> see also 
> unsafePerformIO. I am questioning (a) the exact relation between monads, 
> monadic IO, IO in general and (b) whether the impure restriction is actually 
> a warranted restriction, which relates to, what I find, strange evaluation 
> behavior of the IO monad.
> 
> What is the difference between putStr "a", (putStr "a", putStr "a"), putStr 
> (putStr "a"), putStr (show (putStr "a"))?
> 
> At the moment objects of type IO a _only_ get evaluted when they are the 
> _sole_ result of a Haskell program. What kind of strange dichotomy is that?

A haskell program has the type IO () and will be executed bu the haskell
runtime. The situation is a little more fuzzy when you use a interpreter.
The interpreters usualy execute entered expressions of type IO a, and
evaluate all other expressions. I can agree that this might not be
obvious.
 
/Lars L