| Due to HN's limitations, I can't reply to your reply, but I can reply here instead. :) I'm not sure this is a helpful metaphor, but I don't think it's completely awful: Think of a world state as being a variable representing a timestamp. Until the state is used up, the variable is empty. Suppose I read from a file. I get a brand new state back from the file-reading action -- let's call it WorldState1 -- whose contents are "The time is now X." We don't have a value in X, it's just a variable. (You could think of it as "The time is now <NULL>" if that makes more sense.) Later, when we use our world state in a subsequent action, X is resolved to an actual time. Now, WorldState1 means "the time is now 09:57:53.00001". Later in your program (say, 09:57:53.00999), you try to reuse the same state. The system tries to write the current timestamp (.00999) into the state variable... but it fails, because the state already contains a value. The system requires that these variables can only be written once. If these states existed at runtime, you would get a runtime error in your program. Instead, the type-checker simulates the execution of your program during compilation, realizes that the state would be written twice, and raises a compile-time error. Again, it's just a metaphor. But hopefully it helps to get an intuition about these usable-once-only values. ----- The problem with metaphors is that there are so many of them, and they are all wrong. :) I just thought of another that might click better. Think of a world state as a container that is holding a little bit of potential energy. Like a tiny battery. Every time you take an I/O action, you need to power it up. An I/O action converts potential energy into kinetic energy. Once you use up a world state in an action, the battery is drained. It can't be recharged, so the battery is just dead. Fortunately, each I/O action returns, along with its output, a brand new little battery that you can pass on to the next action. At any point in your program, you have exactly one charged battery on hand (and a pile of used-up ones). So it only makes sense to use the charged one in your next I/O action. |