4 ms·

I think the more important part in the case of the IO monad is not that it might fail, but that it’s a side effect in a lazy language. Not super sure though. Ha

by skavi 5y ago

I think the more important part in the case of the IO monad is not that it might fail, but that it’s a side effect in a lazy language. Not super sure though. Haven’t used much Haskell.

kaba0 5y ago
Laziness is besides the point, scala (and pretty much every language) can do laziness without monads, it is as simple as if private variable == null, then initialize, and then return that variable on every getter call. It is “needed” due to pureness - without haskell’s unsafe, there is no other way to do side-effects[1]. But you are otherwise right. The reason it is beneficial in FP languages is that the optimizer can reason very well about these pure expressions. [1] though execution itself can be considered a side-effect, and haskell code can throw exceptions, so it is more like compartmentalizing the majority of effects
- dllthomas 5y ago
  On the contrary, purity is needed because of laziness! https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing... Not, mind you, merely the possibility of laziness; as you say, you can do that without monads or purity. But with pervasive laziness it becomes difficult to reason about the precise order in which thunks will be evaluated and be sure that (say) the warning will be printed before the missiles are fired instead of after. With purity it (mostly) doesn't matter the precise evaluation order, so (again, in the setting of pervasive laziness) we want that wherever we can have it! But at some point we need to actually fire those missiles and print those messages. The Monad interface for IO, in chaining together effectful computations with bind, makes the input of later computations depend on the output of earlier computations such that the regular data dependencies between the thunks ensure that things happen in the order we asked for.
- ParetoOptimal 5y ago
  > Laziness is besides the point, scala (and pretty much every language) can do laziness without monads, it is as simple as if private variable == null, then initialize, and then return that variable on every getter call. Laziness is also better for composition and local reasoning because you can refactor out any subexpression.

by skavi 5y ago

I think the more important part in the case of the IO monad is not that it might fail, but that it’s a side effect in a lazy language. Not super sure though. Haven’t used much Haskell.

kaba0 5y ago

Laziness is besides the point, scala (and pretty much every language) can do laziness without monads, it is as simple as if private variable == null, then initialize, and then return that variable on every getter call. It is “needed” due to pureness - without haskell’s unsafe, there is no other way to do side-effects[1]. But you are otherwise right. The reason it is beneficial in FP languages is that the optimizer can reason very well about these pure expressions. [1] though execution itself can be considered a side-effect, and haskell code can throw exceptions, so it is more like compartmentalizing the majority of effects

dllthomas 5y ago
On the contrary, purity is needed because of laziness! https://www.microsoft.com/en-us/research/publication/wearing-hair-shirt-retrospective-haskell-2003/ https://www.microsoft.com/en-us/research/publication/wearing... Not, mind you, merely the possibility of laziness; as you say, you can do that without monads or purity. But with pervasive laziness it becomes difficult to reason about the precise order in which thunks will be evaluated and be sure that (say) the warning will be printed before the missiles are fired instead of after. With purity it (mostly) doesn't matter the precise evaluation order, so (again, in the setting of pervasive laziness) we want that wherever we can have it! But at some point we need to actually fire those missiles and print those messages. The Monad interface for IO, in chaining together effectful computations with bind, makes the input of later computations depend on the output of earlier computations such that the regular data dependencies between the thunks ensure that things happen in the order we asked for.
ParetoOptimal 5y ago
> Laziness is besides the point, scala (and pretty much every language) can do laziness without monads, it is as simple as if private variable == null, then initialize, and then return that variable on every getter call. Laziness is also better for composition and local reasoning because you can refactor out any subexpression.