
On Thursday, 2003-08-14, 13:37, CEST, blaat blaat wrote:
[...]
Hello, I don't know exactly which of the following questions have already been answered but I decided to answer them all anyway.
What is the difference between putStr "a", (putStr "a", putStr "a"), putStr (putStr "a"), putStr (show (putStr "a"))?
As I stated earlier, IO a denotes an I/O action which has a result of type a. So the above expressions have the following meaning: putStr "a": an I/O action outputting the string "a" (putStr "a",putStr "a"): a pair of two I/O actions, both outputting the string "a" (This pair is not executable like an I/O actions is.) putStr (putStr "a"): illegal expression because the argument of putStr has to be of type String but putStr "a" has type IO () putStr (show (putStr "a")): For this to work, IO () has to be an instance of class Show which roughly means it must be convertable into a string. putStr "a" is the I/O action which outputs "a" (see above). With a appropriate Show instance, show (putStr "a") would yield a string representation of this I/O action. putStr (show (putStr "a")) would be an I/O action which outputs this string representation.
At the moment objects of type IO a _only_ get evaluted when they are the _sole_ result of a Haskell program.
I/O expressions get evaluated the same way every other expression does. But theit resulting I/O actions get *executed* only under a certain condition. And the condition is that the action in question has to be a part of the main I/O action. Evaluating an expression of type IO a doesn't mean to execute it but to "calculate the I/O action". Since Haskell is pure, expression evaluation never does any I/O. I/O actions are not executed by expression evaluation but because the meaning of a Haskell program is to execute main.
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...)?
Yes, they *describe* impure programs. But as I just said, evaluating the actions doesn't mean to execute them.
[...]
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?
Yes, there is nothing magical about monads. They are just an abstract concept which fits nicely in the context of building descriptions of actions. And there are other ways of constructing such descriptions (as someone already mentioned).
[...]
From: Derek Elkins
To: "blaat blaat" , haskell-cafe@haskell.org
[...]
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.
Exactly.
[...]
Wolfgang