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