4 ms·

Yes, Haskell is a very flawed language, however: (0) The fact you need to modify value-level code to put it in a monadic context is a defect of Haskell's desig

Yes, Haskell is a very flawed language, however: (0) The fact you need to modify value-level code to put it in a monadic context is a defect of Haskell's design, not of monads per se. See: http://www.cs.umd.edu/~mwh/papers/monadic.pdf http://www.cs.umd.edu/~mwh/papers/monadic.pdf (1) Laziness has nothing to do with being purely functional.

comex 10y ago
I'm not even trying to criticize Haskell, really; Haskell has plenty of great attributes (though the paper you linked is interesting). I just think this particular argument advocating for it is poorly constructed, basically pointing to a weakness as if it were a strength.
klodolph 10y ago
On the second point, laziness and purity are very closely related. See http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... (§3.2) See http://stackoverflow.com/questions/31477074/how-lazy-evaluation-forced-haskell-to-be-pure http://stackoverflow.com/questions/31477074/how-lazy-evaluat...
- catnaroek 10y ago
  Maybe for social reasons. From a purely technical standpoint: (0) You can have a pure strict language just fine. You can also have a lazy impure language just fine. (1) Nontermination is an effect anyway, so Haskell isn't pure unless you wish nontermination out of existence. (Which the Haskell community is in the habit of doing.)
  - klodolph 10y ago
    I think you may have glossed over that paper I linked. No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional. https://en.wikipedia.org/wiki/Strict_programming_language https://en.wikipedia.org/wiki/Strict_programming_language Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou... On your second point, nontermination is treated semantically as a value in Haskell. It is an error to consider nontermination an "effect". See: https://en.wikibooks.org/wiki/Haskell/Denotational_semantics https://en.wikibooks.org/wiki/Haskell/Denotational_semantics In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.
    - catnaroek 10y ago
      > I think you may have glossed over that paper I linked. I've read it before, and not precisely yesterday or today. > No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. Sure, such a language wouldn't be very usable, but it's very much definable. > See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. You don't need to convince me that lazy I/O is a bad idea. If it were up to me, the type of a lazy stream would be: data Stream m a = Nil | Cons a (m (Stream m a)) Where m is Identity when you have a strict (and guaranteed finite!) list. Of course, laziness is a monadic effect just like any other. > On your second point, nontermination is treated semantically as a value in Haskell. Nothing is a value in Haskell. (If you work out the operational semantics of a non-strict language, you'll see that you don't need to “carve out” a subset of terms that must be considered “values”, unlike the case for a strict language.) All you have is computations, some terminating, some not.
      - klodolph 10y ago
        These comments seem to be redefining words each time they are used. A parent comment refers to "value-level code" in Haskell and now this comment says that "nothing is a value in Haskell". This seems to be contradictory. It's hard to come to any other conclusion here—other than the conclusion that the author of these comments wishes to argue rather than discuss. There's a lot to learn from the Haskell community if you're willing. For example, there's probably about two decades of work that's been done past the definition of lazy streams which you provide. Conduit, iteratee, pipes, etc. Really cool stuff with stream fusion rules and bounded resource usage.
        catnaroek 10y ago
        Errr, oops, yes, my bad. I should've said term-level code.
marcosdumay 10y ago
About #0, it would be very, very interesting to see how that works on practice. There has just been a big debate on the Haskell community over extending the do notation to work with applicatives, instead of only monads. The pro side won, and it's already on GHC 8. It's too early to be sure, but it didn't seen to break anything yet. The article suggests extending it into pure values too (so that you don't actually need the "do" part). I think all the same arguments apply, so it may be a good move.

comex 10y ago

I'm not even trying to criticize Haskell, really; Haskell has plenty of great attributes (though the paper you linked is interesting). I just think this particular argument advocating for it is poorly constructed, basically pointing to a weakness as if it were a strength.

klodolph 10y ago

On the second point, laziness and purity are very closely related. See http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor... (§3.2) See http://stackoverflow.com/questions/31477074/how-lazy-evaluation-forced-haskell-to-be-pure http://stackoverflow.com/questions/31477074/how-lazy-evaluat...

catnaroek 10y ago
Maybe for social reasons. From a purely technical standpoint: (0) You can have a pure strict language just fine. You can also have a lazy impure language just fine. (1) Nontermination is an effect anyway, so Haskell isn't pure unless you wish nontermination out of existence. (Which the Haskell community is in the habit of doing.)
- klodolph 10y ago
  I think you may have glossed over that paper I linked. No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. I am not aware of any such language. According to Wikipedia, Miranda and Clean are also non-strict but they are also purely functional. https://en.wikipedia.org/wiki/Strict_programming_language https://en.wikipedia.org/wiki/Strict_programming_language Haskell allows you to create non-strict impure code using functions like unsafeInterleaveIO, this is generally regarded as a bad idea for technical reasons except in very special cases. See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. http://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o http://stackoverflow.com/questions/5892653/whats-so-bad-abou... On your second point, nontermination is treated semantically as a value in Haskell. It is an error to consider nontermination an "effect". See: https://en.wikibooks.org/wiki/Haskell/Denotational_semantics https://en.wikibooks.org/wiki/Haskell/Denotational_semantics In short, a function which does not terminate is said to return ⊥ from a semantic perspective. The monotonicity of Haskell functions is what makes this work as you'd expect without violating purity, since ⊥ is the least element.
  - catnaroek 10y ago
    > I think you may have glossed over that paper I linked. I've read it before, and not precisely yesterday or today. > No, you can't have a non-strict impure language just fine, the semantics would make it too difficult to reason about side effects. Sure, such a language wouldn't be very usable, but it's very much definable. > See for example Data.ByteString.Lazy.readFile, which is more or less obsolete since the creation of iteratees. You don't need to convince me that lazy I/O is a bad idea. If it were up to me, the type of a lazy stream would be: data Stream m a = Nil | Cons a (m (Stream m a)) Where m is Identity when you have a strict (and guaranteed finite!) list. Of course, laziness is a monadic effect just like any other. > On your second point, nontermination is treated semantically as a value in Haskell. Nothing is a value in Haskell. (If you work out the operational semantics of a non-strict language, you'll see that you don't need to “carve out” a subset of terms that must be considered “values”, unlike the case for a strict language.) All you have is computations, some terminating, some not.
    - klodolph 10y ago
      These comments seem to be redefining words each time they are used. A parent comment refers to "value-level code" in Haskell and now this comment says that "nothing is a value in Haskell". This seems to be contradictory. It's hard to come to any other conclusion here—other than the conclusion that the author of these comments wishes to argue rather than discuss. There's a lot to learn from the Haskell community if you're willing. For example, there's probably about two decades of work that's been done past the definition of lazy streams which you provide. Conduit, iteratee, pipes, etc. Really cool stuff with stream fusion rules and bounded resource usage.
      - catnaroek 10y ago
        Errr, oops, yes, my bad. I should've said term-level code.

marcosdumay 10y ago

About #0, it would be very, very interesting to see how that works on practice. There has just been a big debate on the Haskell community over extending the do notation to work with applicatives, instead of only monads. The pro side won, and it's already on GHC 8. It's too early to be sure, but it didn't seen to break anything yet. The article suggests extending it into pure values too (so that you don't actually need the "do" part). I think all the same arguments apply, so it may be a good move.