Yes, I'm following it too, and it seems to me that Harper just allows his dislike for Haskell to take advantage of his judgement. Monads as a way to deal with laziness are a very common misconception. Отправлено с iPhone May 2, 2011, в 11:54, Ketil Malde написал(а):

I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business.

Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me:

"There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness."

My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String -> String' function and converting it into an exectuable program) to build real programs from.

Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that?

-k

¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2011/5/2 Ketil Malde :

"There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness."

My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. [...]

Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that?

I agree with your analysis. Throughout his different articles, I think Harper partly has a point when he says that laziness brings certain disadvantages (like e.g. complex memory and CPU behaviour) to Haskell (although I disagree with some of his other arguments here). However, like you say, he misses the ball by amalgamating laziness with referential transparency, where the first probably requires the second but not vice versa. This allows him to simply dismiss both, which is convenient for his apparent conclusion that "ML is strictly better than Haskell", since referential transparency and purity are (in my view) one of the things ML lacks most when compared to Haskell. His only other argument against referential transparency and purity seems to be his mentioning of "benign effects", which is weak for two reasons: first, benign effects are clearly not what typical ML programs use non-purity for and second, benign effects can be supported much more conservatively using Haskell's unsafePerformIO. Dominique

I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business.

Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me:

"There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness."

My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String -> String' function and converting it into an exectuable program) to build real programs from.

Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that?

-k

¹ http://existentialtype.wordpress.com/ Interesting how I have been authoring and subsequently using monads in scala for several years and it is strictness that gets in the way more

On 02/05/11 17:54, Ketil Malde wrote: than anything. http://github.com/scalaz/scalaz/ I have been teaching functional programming for quite a while, both in universities and outside of academia, and I am of the opinion that Haskell's suitability in first place has no close second place. I wonder why I am wrong, but this post (and previous) is hardly persuasive. -- Tony Morris http://tmorris.net/

For a historical perspective, I highly recommend The Definitive Account of the History of Haskell: http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-hask... Section 7 clearly and directly cites the desire to have pure I/O as the motivation for adopting monads. As you are saying that doesn't directly contradict the statement of Bob that you cite. In fact, Section 3.2 of the above paper supports the opinion that purity is a consequence of choosing to be lazy, but it also claims that the "combination of power and beauty" of a pure language motivated the language designers. Interestingly, today (at least the academic fraction of) the Haskell community appears to hold the purity of the language in higher regard than its laziness. Manuel Ketil Malde:

I'm following Harper's blog, Existential Type¹, which I find to be an enjoyable and entertainingly written tirade about the advantages of teaching functional programming - specifically ML - to students. Of course, he tends to be critical of Haskell, but it's nice to get some thought provoking opinion from somebody who knows a bit about the business.

Recently, he had a piece on monads, and how to do them in ML, and one statement puzzled me:

"There is a particular reason why monads had to arise in Haskell, though, which is to defeat the scourge of laziness."

My own view is/was that monads were so successful in Haskell since it allowed writing flexible programs with imperative features, without sacrificing referential transparency. Although people are quick (and rightly so) to point out that this flexibility goes way beyond IO, I think IO was in many ways the killer application for monads. Before IO, we had very limited functionality (like 'interact' taking a 'String -> String' function and converting it into an exectuable program) to build real programs from.

Laziness does require referential transparency (or at least, it is easier to get away with the lack of RT in a strict language), so I can see that he is indirectly correct, but RT is a goal in itself. Thus, I wonder if there are any other rationale for a statement like that?

-k

¹ http://existentialtype.wordpress.com/ -- If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe