"Actually, the problem with Monads in other languages is that they do disappear behind the statement separator (semi-colon in many languages)... The Monad pattern appears everywhere in every language whether you know it or not, Haskell merely exposes to the user something that is already there. "
Yes I agree (haskeller myself). The "disappearance" I meant was addressing the original point of view that the repetition of the pattern was a weakness in the language, something like Visitor pattern disppearing in Common LIsp. (an intriguing idea to play with and a valid point of view). Your interpretation of disappearance goes the other way - something like continuations being hidden in fortran and explcit in Scheme.
"Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell."
A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"?
And come on, no one is really "accusing" Haskell of anything. I for one, like the language a lot.
If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
> If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.
Clean's uniqueness types have the distinction that you can e.g. in theory split the state of the world, thread it to two different function and then put it back together, and make the type system ensure safety.
Monads have the distinction that they are not only easy to compose but that composability is baked right into their very definition (and laws).
Functional reactive programming might be a good alternative model for I/O and some other things where monads are used. Also arrows seems to be worth more investigation.
Arrows are in a lot of cases the more apt structure that monads. The reason arrows aren't used more in Haskell already is that the monads have such a nice syntax.
> A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"?
To clarify this, here's a couple of questions whose answers might amuse you.
Is it possible to implement explicit continuations in terms of monads?
Is it possible to implement monads in terms of explicit continuations?
If it is possible to implement A in terms of B (and not vice versa), then B is more basic than A.
That's why I prefer Ruby over Python. It unifies loops and iterators using closures. At the same time the syntax "pretends" to be simple so that you can start using Ruby straight away without having to understand continuations and closures. But I think a language which manages to hide the complexity of monads without removing them will blow Clojure out of the water.
> I think a language which manages to hide the complexity of monads without removing them
Hm, I'm not sure this is possible: a great part of the "complexity" of monads is because it's a similar (and fairly simple!) structure that applies to a great many apparently unrelated concepts: function sequencing, backtracking, and what have you.
Yes I agree (haskeller myself). The "disappearance" I meant was addressing the original point of view that the repetition of the pattern was a weakness in the language, something like Visitor pattern disppearing in Common LIsp. (an intriguing idea to play with and a valid point of view). Your interpretation of disappearance goes the other way - something like continuations being hidden in fortran and explcit in Scheme.
"Accusing Haskell of being "less advanced" because it actually exposes Monads to you and permits you to use them is very much like accusing C++ of lacking power vs. C because it permits you to overload the square brackets. If you put aside the question of whether it's a good thing to have the power (a separate debate in both cases), it's not a very sensible accusation to level against Haskell."
A better analogy would be an argument about exposing call/cc in scheme. Is call/cc good language design? There are arguments on both sides. Haskell does continuations differently than Scheme. Which is "better"?
And come on, no one is really "accusing" Haskell of anything. I for one, like the language a lot.
If you will, think of this as a speculation about a successor language. 15 years from now (say) there will be a better language than Haskell in the statically typed lazy functional languages space, which absorbs the key positives of Haskell, has a few new ideas, and possibly treats Monads differently (or does away with them altogether). Clean (the language) deals with IO with uniqueness types with nary a monad in sight. Is that design "better"? Worth thinking about.