[gmfawcett]

A less poetic way of stating it: if you re-use an already-used world state, you are violating a logical constraint of the system. No timelines will be violated, you just have an invalid program.

World states are supposed to consumed once only: they are "linearly typed" in fancy language. But Haskell cannot directly enforce the linear-type constraint on world states, so in theory these states could be used more than once. Fortunately, the IO monad encapsulates (hides) the states, so that you can't make this mistake in your application code -- you can't reuse what you can't access.

World-states in Haskell aren't first-class values. They aren't actual objects that are being passed around during the execution of the program. They are more like tokens that exist during type checking, but are erased when the program is compiled or interpreted.

Another way of phrasing it is that Haskell interpreters/compilers have specialized support for the IO monad: during type checking, it acts as if these states exist, but they have no operational meaning in the executed program.

[sullyj3]

> you are violating a logical constraint of the system

I'm looking for something even a little more concrete than this. Why would the program be invalid? Can you give an example of what would happen if we just went ahead and accessed a worldstate a second time, logical constraints be damned?

[goto11]

One of the operations using the same worldstate might not get executed, or the operations might happen in unpredictable order.

[gmfawcett]

In a language like Mercury where the IO states are explicit, this would be true. You can run IO in reverse in Mercury if you want:

    main(IO_In, IO_Out) :-
      print_line("This will print last", IO_1, IO_Out),
      print_line("This will print first", IO_In, IO_1).

But in Haskell, the world states aren't accessible to the programmer. It's misleading to suggest what could happen in Haskell if you reused a world state, because it's impossible to do so.