Re: [Haskell-cafe] On the purity of Haskell

...

Anyway, if you're using IO actions, your code is not referentially transparent and is therefore impure - by your own definition of "impure". Causing side-effects may not be pedantically the issue, but the mix of causing and reacting to them - ie interacting with the "outside" - clearly means that some of your function results are dependent on what's happening "outside" your program. That includes side-effects "outside" your program yet caused by program program. No, code can be referential transparent and pure and at the same time use IO actions. In order to understand that, you need to untangle the notion you describe above as "function result" from Haskell function value. We can talk endlessly about what your external/execution results might be for some IO action, but at the formulaic level of a Haskell

Quoth Steve Horne, ... program it's a simple function value, e.g., IO Int. To me, that only makes sense if you never run the compiled program - if

On 29/12/2011 18:04, Donn Cave wrote: the executable file is just an interesting artifact that you generated using a Haskell "interpreter". In reality, the behaviour of IO actions is part of Haskell. The precise meaning of primitive Haskell IO actions is defined. The effects of compositing to build larger IO actions is defined. The Haskell language and compiler take responsibility for meaning of IO actions. The effect of executing those actions, including the returned values, is absolutely relevant to the behaviour of the program. You can make the argument that "the world" is a parameter. Well - in C, "the world" can be considered an implicit parameter. In any case, this only gives referential transparency by what I'd call deceptive definition. Only a tiny piece of "the world" is relevant to your program. You've buried the relevant in a mass of the irrelevant, very much like a less-than-transparent politician. Your interaction is no more or less likely to have bugs depending on whether you define this as transparent or not - arguing about the definition is besides the point. If a program that causes and is sensitive to side-effects - that interacts with the outside world - is referentially transparent, then referential transparency has no relevant meaning.