3 ms·

If you start with an impure lazy programming language, you will very quickly discover that you may as well make it pure and handle side effects through an IO ty

by tome 2y ago

If you start with an impure lazy programming language, you will very quickly discover that you may as well make it pure and handle side effects through an IO type. Specifically, it would be far too hard to perform effects in the correct order without an IO monad. I wrote up an explanation: http://h2.jaguarpaw.co.uk/posts/impure-lazy-language/ http://h2.jaguarpaw.co.uk/posts/impure-lazy-language/

tasuki 2y ago
If you start with a pure and strict programming language, how will you handle side effects?
- kccqzy 2y ago
  The same way as a pure and lazy programming language. That is to say, the IO monad. This abstraction works for both lazy and eager evaluation because it's internally just passing a token from function to function. When you have something like `doThis >> doThat` (two actions sequentially) the first action results in a token (RealWorld#) that must be passed into the second action. Even though the evaluation of the two actions may be undetermined in a lazy language (but determined in a strict language), the token being passed around has a definite order.
  - tasuki 2y ago
    That was kind of my point, but thanks for laying it out nicely, I guess :)
- mcguire 2y ago
  Side effects like IO are very difficult to handle in a pure language. I believe Simon Peyton Jones' argument was that, if it's strict, there is too much of a temptation to say, "screw it", and abandon purity. https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing...
  - tasuki 2y ago
    Much respect for Simon Peyton Jones, but empirically, that's not true: see Idris, PureScript, Elm, and probably many others.
    - mcguire 2y ago
      Those were all designed after monadic IO was introduced in Haskell. The ability to mark IO operations in types (and the do notation) was a game-changer.

by tome 2y ago

tasuki 2y ago

If you start with a pure and strict programming language, how will you handle side effects?

kccqzy 2y ago
The same way as a pure and lazy programming language. That is to say, the IO monad. This abstraction works for both lazy and eager evaluation because it's internally just passing a token from function to function. When you have something like `doThis >> doThat` (two actions sequentially) the first action results in a token (RealWorld#) that must be passed into the second action. Even though the evaluation of the two actions may be undetermined in a lazy language (but determined in a strict language), the token being passed around has a definite order.
- tasuki 2y ago
  That was kind of my point, but thanks for laying it out nicely, I guess :)
mcguire 2y ago
Side effects like IO are very difficult to handle in a pure language. I believe Simon Peyton Jones' argument was that, if it's strict, there is too much of a temptation to say, "screw it", and abandon purity. https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing...
- tasuki 2y ago
  Much respect for Simon Peyton Jones, but empirically, that's not true: see Idris, PureScript, Elm, and probably many others.
  - mcguire 2y ago
    Those were all designed after monadic IO was introduced in Haskell. The ability to mark IO operations in types (and the do notation) was a game-changer.