[Haskell-cafe] On the purity of Haskell

[Chris Smith]

On Thu, 2011-12-29 at 18:07 +0000, Steve Horne wrote:
> By definition, an intentional effect is a side-effect. To me, it's by 
> deceptive redefinition - and a lot of arguments rely on mixing 
> definitions - but nonetheless the jargon meaning is correct within 
> programming and has been for decades. It's not going to go away.
> 
> Basically, the jargon definition was coined by one of the pioneers of 
> function programming - he recognised a problem and needed a simple way 
> to describe it, but in some ways the choice of word is unfortunate.

I don't believe this is true.  "Side effect" refers to having a FUNCTION
-- that is, a map from input values to output values -- such that when
it is evaluated there is some effect in addition to computing the
resulting value from that map.  The phrase "side effect" refers to a
very specific confusion: namely, conflating the performing of effects
with computing the values of functions.

Haskell has no such things.  It's values of IO types are not functions
at all, and their effects do not occur as a side effect of evaluating a
function.  Kleisli arrows in the IO monad -- that is, functions whose
result type is an IO type, for example String -> IO () -- are common,
yes, but note that even then, the effect still doesn't occur as a side
effect of evaluating the function.  Evaluating the function just gives
you a specific value of the IO type, and performing the effect is still
a distinct step that is not the same thing as function evaluation.

> You can argue pedantry, but the pedantry must have a point - a 
> convenient word redefinition will not make your bugs go away. People 
> tried that with "it's not a bug it's a feature" and no-one was impressed.

This most certainly has a point.  The point is that Haskell being a pure
language allows you to reason more fully about Haskell programs using
basic language features like functions and variables.  Yes, since
Haskell is sufficiently powerful, it's possible to build more and more
complicated constructs that are again harder to reason about... but even
when you do so, you end up using the core Haskell language to talk
*about* such constructs... you retain the ability to get your hands on
them and discuss them directly and give them names, not mere as side
aspects of syntactic forms as they manifest themselves in impure
languages.

That is the point of what people are saying here (pedantry or not is a
matter of your taste); it's directly relevant to day to day programming
in Haskell.

-- 
Chris Smith