[DanWaterworth]

> the way it manages side effects is that it does so through lazy evaluation

This is actually not true. Lazy evaluation forced Haskell to stay pure, but it is purity that provides the tools for constraining effects. You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

[hisham_hm]

> You could have a strict Haskell-like language that manages effects in the same way, indeed such languages exist.

I'm unaware of any strict purely functional language with monads. Could you give an example? Thanks!

[DanWaterworth]

Idris is one example.

[freyrs3]

Disciple[1], and I believe "Mu" Haskell ( the Standard Chartered dialect ) though I don't know for sure because it's not open source.

[1]: http://disciple.ouroborus.net/

[pron]

Isn't the side effect returned as an IO type which is later evaluated by the runtime? (I'm talking about Haskell)

[DanWaterworth]

Yes, but you can create the thing of type `IO a` strictly.

[pron]

Yes, but when are they executed? When is the byte written to the file?

[DanWaterworth]

Well, you certainly can't start executing until the `IO a` thing has been evaluated, but there aren't any other constraints.

Something that can confuse people (and I'm not sure if this is the case with you or not) is that an `IO a` may/probably will contain a closure. So evaluation and execution are interleaved, but not because of laziness.

[dllthomas]

Closures can be a way of implementing laziness, so I'm not sure you've shown it's "not because of laziness" - though certainly it's not because the language is lazy by default.

[quchen]

You can picture functions with the IO type as something to compose a program out of. This program is then run by runtime system of your implementation, and that's "when the byte is written".

Here's a nice explanation of Haskell IO: http://stackoverflow.com/questions/13536761/what-other-ways-...