> (cons :a (cons :b '())) ≠ (cons :b (cons :a '())) In less idiosyncratic syntax, this says that the list [a, b] is not equal to the list [b, a]. That's the ca

> (cons :a (cons :b '())) ≠ (cons :b (cons :a '())) In less idiosyncratic syntax, this says that the list [a, b] is not equal to the list [b, a]. That's the case in all languages (at least, it should be!). The order of execution is about the same value being calculated along different paths. For example, we can consider the value [write("foo", /tmp/x), read(/tmp/x)]. Here's one path: [write("foo", /tmp/x), read(/tmp/x)] [null, read(/tmp/x)] [null, "foo"] Here's another: [write("foo", /tmp/x), read(/tmp/x)] [write("foo", /tmp/x), "previous content"] [null, "previous content"] These values aren't equal, so the path taken by the interpreter/compiled-code can affect what our program does! In contrast, we could follow an approach like Haskell and encapsulate IO actions as standalone values. This gives one path: [write("foo", /tmp/x), read(/tmp/x)] [<Some IO action>, read(/tmp/x)] [<Some IO action>, <Other IO action>] Here's another path: [write("foo", /tmp/x), read(/tmp/x)] [write("foo", /tmp/x), <Other IO action>] [<Some IO action>, <Other IO action>] These are equal, so we don't have to worry about the path taken affecting out outcome. We do have to worry whether the chosen path will produce an outcome at all, since it's possible that a program gets caught in an infinite loop even if it's avoidable. We can remove this worry if we use lazy evaluation.