Yet Another Monad Tutorial
Thu, 14 Aug 2003 13:37:39 +0200
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
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 <firstname.lastname@example.org>
>To: "blaat blaat" <email@example.com>, firstname.lastname@example.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
> > 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.
MSN 8 with e-mail virus protection service: 2 months FREE*