Yet Another Monad Tutorial

[Derek Elkins]

On Wed, 13 Aug 2003 13:26:34 +0200
"blaat blaat" <l4t3r@hotmail.com> wrote:

I have a long reply, perhaps I'll post it later.  Here's a more
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"?  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?

> Think of the following though experiment. What if I would have a
> function "unparse:IO a->String" which gives the textual representation
> of the specification of the object of type IO a? Clearly, IO is not a
> monad anymore. Moreover, I don't think it would break the purity of
> Haskell. And surely, in case of the IO monad, we can think of better
> manners to break a program down.

Keith has already pointed out the flagrant error here; which I also
point out in my long reply. But again, the questions...

What is unparse supposed to return?  What does it have to do with IO in
particular, i.e. why do I want to unparse IO computations especially? 
Why can't it be done with (or over) the current IO monad?  What other
ways do you want to breakdown a program, still resulting in
understandable behavior, but can't because of the IO monad?

> Hmm, I am rambling. The point is, I think there is no reason to
> discard all alternatives to monads; 

> 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 have comments for these too, but I'll keep this short.  Basically, I
don't really see how what you want has all that much to do with IO in
general, and I don't see monads get in the way.