const io_actions = ["hello", "world"].map(s => () => console.log(s));
io_actions[1]();
which also prints "world" when the JavaScript runtime evaluates the code. const io_actions = ["hello", "world"].map(s => () => console.log(s));
io_actions[1]();
which also prints "world" when the JavaScript runtime evaluates the code.If you say that purity and referential transparency are not only reserved for Haskell then again technically sure, but the point of Haskell is that it makes these concepts the centre of its design. Instead of having to jump through hoops to write code where you can do the above you have to jump through hoops to do the opposite.
IO functions like putStrLn is curried by default, so you can pass them around without executing them. But this does not affect the purity of executing them. And it is not something special for Haskell, you can pass functions around without executing them in almost any language.
The cool thing about Haskell is that code is pure by default, and it is only due to special-casing by the language (the type of "main" being "IO ()") that you can even have operations with side-effects.
Haskell allows you to have parts of the program guaranteed pure, but the program is a whole is not pure if it does any input/output.
It will not be executed until the very last line of your app.
O_O
No seriously. If you wanted to model IO in say Java. Your whole program would be about constructing values. No I/O what so ever. Only do this then that then get a, then if a is this do x other.....
Whole Java app and I/O would only happen when at the very end you execute run method on that constructed value.
That'd not usual Java. After all in Java code itself can do control flow and I/O. Do why bother with those values. Need I/O on line ten out of 100. Do I/O immediately on line 10.
What I/O on Haskell is is side effect. Explicit side effect.
It's possible to write impure code in Haskell but that is not IO. It's when you use escape hatches that break type system guarantees.