Steve Horne wrote:
Heinrich Apfelmus wrote:
Purity has nothing to do with the question of whether you can express IO in Haskell or not.
....
The beauty of the IO monad is that it doesn't change anything about purity. Applying the function
bar :: Int -> IO Int
to the value 2 will always give the same result:
Yes - AT COMPILE TIME by the principle of referential transparency it always returns the same action. However, the whole point of that action is that it might potentially be executed (with potentially side-effecting results) at run-time. Pure at compile-time, impure at run-time. What is only modeled at compile-time is realized at run-time, side-effects included.
Well, it's a matter of terminology: "impure" /= "has side effects". The ability of a language to describe side effects is not tied to its (im)purity. Again, purity refers to the semantics of functions (at run-time): given the same argument, will a function always return the same result? The answer to this question solely decides whether the language is pure or impure. Note that this depends on the meaning of "function" within that language. In C, side-effects are part of the semantics of functions, so it's an impure language. In Haskell, on the other hand, functions will always return the same result, so the language is pure. You could say that side effects have been moved from functions to some other type (namely IO) in Haskell. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com