In computer science, a function or expression is VVVVVVVVVVVVVVVVVVVVVVVV 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. Donn