On Sat, Mar 17, 2012 at 5:41 AM, Donn Cave
I hope the answer is not that in computer science we regard all effects as side effects because the ideal computer program simply exists without consequence.
The answer is that side effects has become something of a figure of speech, and now has a specialized meaning in programming languages. When we're talking about different uses of the word "function" in programming languages, side effects refer to any effect other than evaluating to some result when applied to some argument. For example, in languages like C, printf takes some arguments, and returns an int. When viewed as just a function, that's all there is to it; functions exist to take arguments and produce return values. But C extends the definition of a function to include additional effects, like making "Hello world" appear on a nearby computer screen. Because those effects are "aside from" the taking of arguments and returning of values that functions exist to do, they are "side effects"... even though in the specific case of printf, the effect is the main goal and everyone ignores the return value, still for functions in general, any effects outside of producing a resulting value from its arguments are "side effects". I suppose Haskell doesn't have "side effects" in that sense, since its effectful actions aren't confused with functions. (Well, except from silly examples like "the CPU gives off heat" or FFI/unsafe stuff like unsafePerformIO.) So maybe we should ideally call them just "effects". But since so many other languages use functions to describe effectful actions, the term has stuck. So pretty much when someone talks about side effects, even in Haskell, they means stateful interaction with the world. -- Chris Smith