[Haskell-cafe] On the purity of Haskell

[Steve Horne]

On 29/12/2011 21:01, Chris Smith wrote:
> 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.
Yes - again, by definition that is true. But that definition is not the 
everyday definition of side-effect. Repeating and explaining one 
definition doesn't make the other go away.

 1. To say that the C printf function has the side-effect of printing to
    the screen - that's true.
 2. To say that the C printf function has no side-effects because it
    works correctly - the only effects are intentional - that's also true.

Two definitions of side-effect. The definition used for case 2 is a lot 
older than the definition used for case 1, and remains valid. It's the 
normal usage that most people are familiar with everywhere - not just in 
programming and computer science.

I haven't failed to understand either definition - I simply accept that 
both are valid. Natural language is ambiguous - sad fact of life.

Using similar mixed definitions to conclude that every C program is full 
of bugs (basically equating intentional effects with side-effects, then 
equating side-effects with unintentional bugs) is a fairly common thing 
in my experience, but it's a logical fallacy. If you aren't aware of the 
two definitions of side-effect, it's hard to get deal with that.

Some people don't want anyone to figure out the fallacy - they like 
having this convenient way to attack C, irrespective of whether it's 
valid or not. Rare I think - mostly it's more confusion and memetics. 
But still, I'm convinced there's some sophistry in this. And I'm not the 
only person to think so, and to have reacted against that in the past.

Extra sad - you don't need that fallacy to attack C. It's redundant. C 
is quite happy to demonstrate its many failings.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111229/751fb3d9/attachment.htm>