Referential transparency
Referential transparency is an oft-touted property of (pure) functional languages, which makes it easier to reason about the behavior of programs. I don't think there is any formal definition, but it usually means that an expression always evaluates to the same result in any context. Side effects like (uncontrolled) imperative update break this desirable property. C and ML are languages with constructs that are not referentially transparent.
As an example, consider the following program in Standard ML:
print "h"; print "a"; print "h"; print "a"
which prints "haha". In an attempt to factor out the repetition, we write
let val ha = (print "h"; print "a") in ha; ha end
but now the laugh is on us, because "ha" is only printed once. The reason is that print's side effect is realized when ha gets bound, so we should have written
let fun ha () = (print "h"; print "a") in ha (); ha () end
Haskell's monadic I/O system distinguishes between values and actions like the print procedure above. So we do indeed have that
putChar 'h' >> putChar 'a' >> putChar 'h' >> putChar 'a'
is equivalent to
let ha = putChar 'h' >> putChar 'a' in ha >> ha
This example is taken from
- Philip Wadler. How to declare an imperative. ACM Computing Surveys, 29(3):240--263, September 1997. [1]
Some definitions of referential transparency are summarized in a USENET post by Tom DeBoni [2]
There is some debate about whether the imprecisely defined semantics of Int breaks referential transparency.
For instance, even (maxBound :: Int) might to true in some contexts and to false in others.
Another example is System.Info.os :: String.
One perspective is that Haskell is not just one language (plus Prelude), but a family of languages, parameterized by a collection of implementation-dependent parameters.
Each such language is RT, even if the collection as a whole might not be.
Some people are satisfied with situation and others are not.