[tome]

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/

[tasuki]

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

[mcguire]

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...

[tasuki]

Much respect for Simon Peyton Jones, but empirically, that's not true: see Idris, PureScript, Elm, and probably many others.

[mcguire]

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.

[kccqzy]

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]

That was kind of my point, but thanks for laying it out nicely, I guess :)