Yet Another Monad Tutorial

[blaat blaat]

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, 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? 
Is not the _only_ interpretation of this dichotomy that objects of type IO 
describe impure programs (composed of actions which are only evaluated 
when...)? And, if so, why can't we decompose these programs (before they get 
evaluated)? 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?

As stated by Keith, deriving show for IO is possible.  In such a setting 
putStr (putStr "a") I imagine returns "putStr \"a\"", which I find far more 
orthogonal than what we have now. (Have to find the reference still). Does 
this boil down to an impure or a pure decomposition?

>From: Derek Elkins <ddarius@hotpop.com>
>To: "blaat blaat" <l4t3r@hotmail.com>, haskell-cafe@haskell.org
>pragmatic short one.
>
> > What did we lose? Well, introspection comes to mind. A monad is
> > strange in the sense that, actually, there does not seem to be any
> > reason to compute its value since we cannot possibly get anything out
> > of it. In case of IO, only the haskell interpreter can. And,
> > introspection is a nice thing to have, especially for compiler
> > writers. Although I think the benefits in Haskell would be limited, an
> > application might be that I could write my own promotion functions on
> > my own programs.
>
>Lot's of issues with this paragraph, but here are the questions.  What
>do you mean by "promotion function"?

Example of promotion: map f . map g = map (f . g)

A promotion function would transform objects of type IO a into objects of 
type IO a while performing promotions.

  How would you write it in your
>hypothetical Haskell?  How is it related to IO? How do monads and/or the
>IO monad in particular cause problems?  Why couldn't the same be done
>using monads or why would it be significantly harder if it can be done?

In a monadic approach, I imagine functions like "unbind" which now would 
break purity.

[..]

> > 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.

I still stand here (but am totally willing to be corrected on this account 
too). Hmpf, maybe someone more enlightened should write a paper on it.

Cheers, l4t3r

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus