Adrian Hey writes:
> Is referential transparency really such a sacred cow? Sometimes
> side effects are useful IMHO e.g. for IO. (Though the Cleaners regard
> IO as being referentially transparent for technical reasons which I
> don't quite understand.)
>
> I've been looking at Concurrent Haskell, and more recently Johan
> Nordlanders O'Haskell. I think there's a good deal of sense in both
> these dialects of Haskell (I especially like the idea of getting rid
> of the evil I:-)
>
> To me, the important thing is that it should be clear when we do and
> when we don't have referential transparency. Where we don't, words
> like 'operation' or 'action' should be used instead of 'function'.
>
> So I can see nothing wrong with encapsulated (mutable) state, in principle,
> just so long as the state is only mutated by 'actions'.
Just to avoid any unfortunate misconceptions: O'Haskell definitely
preserves the property we commonly refer to as referential transparency,
and so does Concurrent Haskell, or any other sound monadic extension of
the language.
But what I think Adrian is advertising here is the beauty of programming
with (state) monads in general -- a command producing a value has a
different type from an expression denoting the same value. O'Haskell
builds its object-oriented state encapsulation on top of this general
idea.
-- Johan
