[Haskell-cafe] side effects (Why Haskell is beautiful to the novice)
donn at avvanta.com
Mon Aug 31 04:54:58 UTC 2015
> In computer science, a function or expression is
> said to have a side effect if, in addition to returning
> a value, it also modifies some state or has an observable
> interaction with calling functions or the outside world.
> You have a function, whose purported effect is to return a
> value. "IN ADDITION TO" that, it has "A SUBSIDIARY CONSEQUENCE",
> "A SECONDARY RESULT". The Wikipedia definition is slightly
> wonky in that if you take it literally, a Fortran subroutine =
> Pascal or Ada procedure = C 'void function' can't have a side
> effect, which is obviously wrong. A subprogram that does not
> return a value *CAN* have a second result other than the one it
> is declared to have, and the need to consider history in
> reasoning about resultless procedures is none the less because
> of this glitch in the Wikipedia's definition.
Ha ha, I think this may be the first time I've seen a wikipedia page
change as a side effect of a discussion that references it.
But the modified definition seems to make even less sense. If I
understand your objection above, the answer could simply be that
these subprograms return a value like our (), for the sake of
semantics. But the new definition requires us to identify a
"purported main effect" in order to say what's a side effect.
If foo :: IO Int prints a string and returns the string's
length, do we need to know how important the string length is
to the caller, or is that as the function type automatically
its purported main effect? I'm sure I've encountered real
life subprograms with two or more main effects.
I'm also troubled by the change from "In functional programming,
side effects are rarely used" to "In functional programming,
effects are rarely used." This must be an error.
More information about the Haskell-Cafe