On 29/12/2011 10:05, Jerzy Karczmarczuk wrote:
Sorry, a long and pseudo-philosophical treatise. Trash it before reading.
Heinrich Apfelmus:
You could say that side effects have been moved from functions to
some other type (namely IO) in Haskell.
I have no reason to be categorical, but I believe that calling the
interaction of a Haskell programme with the World - a "side effect" is
sinful, and it is a source of semantical trouble.
People do it, SPJ (cited by S. Horne) did it as well, and this is too
bad.
People, when you eat a sandwich: are you doing "side effects"?? If
you break a tooth on it, this IS a side effect, but neither the eating
nor digesting it, seems to be one.
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.
The important thing is to make sure that the explanations you trust
aren't based on mixing of the jargon and everyday meanings of
"side-effect". In part that's what my original e-mail is about -
accepting the definitions of side-effect and referential transparency
that are standard within functional programming, eliminating the common
non-sequiturs and seeing if functional programming really does still
make sense at the end.
What would have surprised me when I started this unintentional journey
(each step basically being a rant at one functional programming advocate
or another) is that actually functional programming in Haskell really
does make sense.
This term should be used in a way compatible with its original
meaning, that something happens implicitly, "behind the curtain",
specified most often in an informal way (not always deserving to be
called "operational"). If you call all the assignments "side effects",
why not call - let x = whatever in Something - also a "local
side-effect"?
Oh, that you can often transform let in the application of lambda,
thus purely functional?
Doesn't matter, Steve Horne will explain you that (sorry for the
irony): "let is a compile-time pure construct ; at execution this is
impure, because x got a value".
Well, I was even more absurd than that - in C, I said there were two
values (the "reference" and the value referenced) for every variable.
Sometimes, eliminating all the subtle contradictions necessarily leads
to a much more pedantic world than intuition is happy to deal with.
S.H. admits that he reasons within his model, and has problems with
others. Everybody has such problems, but I see here something the
(true) Frenchies call "un dialogue de sourds". For me a Haskell
programme is ABSOLUTELY pure, including the IO. The issue is that
`bind` within the IO monad has an implicit parameter, the World. In
fact, a stream of Worlds, every putWhatever, getLine, etc. passes to a
new instance.
As I said earlier, a politician who buries the relevant in a huge mass
of the irrelevant is not considered transparent. To call this "world"
parameter referentially transparent is, to me, argument by deceptive
definitions. In any case, the "world" parameter is present in C - it's
just implicit. You can translate C to Haskell and visa versa. Both the C
and Haskell versions of a correctly translated program will have the
same interactions with the world. Therefore there is a mathematical
equivalence between Haskell and C.
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.
Simply, you are not allowed by the Holy Scripts to look under this robe.
Ah yes - well that's exactly what I'm trying to do.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
