...it certianly hasn't been that somebody's evasive or dishonest about the design goals.
When I used the words "They are, emotionally, just a way of concealing the fact that Haskell programs contain code that has state."
I was not saying that there was anything "evasive or dishonest" going on.
Have read both of those papers by SPJ and I have to say, that he is the exception that proves the rule when it comes to straight talking in the Haskell community. Indeed, I've downloaded the latter many times because when I go looking for it, I can never find it because the name (mark.pdf) doesn't ring any damn bells. Last time, I remembered to change the name to something meaningful :)
Anyway, back to what I did mean and using the those papers as exhibits in my defense.
Section 2.1 begins: "We begin with an apparently fundamental conflict. A purely functional program implements
a function; it has no side effect. Yet the ultimate purpose of running a program is invariably
to cause some side effect: a changed file, some new pixels on the screen, a message sent, or
whatever. Indeed it’s a bit cheeky to call input/output “awkward” at all. I/O is the raison d’ˆetre
of every program. — a program that had no observable effect whatsoever (no input, no output)
would not be very useful."
Section 2.2 starts:
"2.2 Monadic I/O
The big breakthrough in input/output for purely-functional languages came when we learned
how to use so-called monads as a general structuring mechanism for functional programs. Here
is the key idea:
A value of type IO a is an “action” that, when performed, may do some input/
output, before delivering a value of type a.
This is an admirably abstract statement, and I would not be surprised if it means almost nothing
to you at the moment.
And moves on through a lot of syntactic and semantic discussion before reaching:
Monads were originally invented in a branch of mathematics called category theory, which is
increasingly being applied to describe the semantics of programming languages. Eugenio Moggi
first identified the usefulness of monads to describe composable “computations” 32. Moggi’s
work, while brilliant, is not for the faint hearted. For practical programmers the breakthrough
came in Phil Wadler’s paper “Comprehending monads” 47, in which he described the usefulness
of monads in a programming context. Wadler wrote several more very readable papers about
monads, which I highly recommend 48, 49, 50. He and I built directly on this work to write the
first paper about monadic I/O 38.
In general, a monad is a triple of a type constructor ...
I wish I could c&p the big lump of algebraic notation that follows, but it suffices.
He starts out saying "functions have no side-effects" and ends up describing how actually, they can. That's smoke and mirrors!
Not in any "deceptive", "evasive" or "dishonest" sense. But in the same sense that "tax avoidance" exploits loopholes in the law. It's not breaking the law, but it still results in you paying less tax than you might otherwise have had to pay.
So "“monad” derived from category theory, one of the most abstract branches of mathematics" is the loophole.
I have no doubt that if I was able to understand the notation and theory behind the concept, that I to could convince myself that theory holds up. But I don't need to do that, because I am happy to take it as read from those that do understand it.
But, IO still has side-effects. And functions that do IO still have side-effects. They haven't disappeared, they've just been moved 'outside of the program' into the world, where they do no harm. In particular, they do no harm to the purity of the lazy functional ethics. and especially, to the compiler magic made possible by the HM type system.
The defensiveness I referred to does not exist because there is anything wrong with the theory underlying monads (I assume :). It arises because actually, there are far more Haskellers that don't fully uunderstand the theory than do, and their defensive posture is to refer questioners to the theory, rather than try and explain it in terms that non-mathematicians can grasp. There is an old saying I cannot remember, that says something to the effect that it takes an expert practitioner--one who really, really understands his subject--to explain complicated things in simple ways.
It's not uncommon. We've all seen the examples of the resident 'expert' asked for an explaination of something complicated, resort to waffling in techno-babble. Most of us have been there at some point or another. It doesn't mean we do not understand. It just means that we have not reached that level of comfort with the subject to be able to de-cloak it from the technicalities as a real expert--and a very few gifted teachers (of anything)--can do.
However, there is a common and unpleasent side-effect [sic] of techno-babble. It is often perceived as condescension. And that can be detrimental.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.