[Haskell-cafe] On the purity of Haskell

[Steve Horne]

On 29/12/2011 18:04, Donn Cave wrote:
> Quoth Steve Horne<sh006d3592 at blueyonder.co.uk>,
> ...
>> 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
> 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 
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.