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 <[EMAIL PROTECTED]> To: "blaat blaat" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
