On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote:
But you can't! I can easily envisage a scenario where there's a link between two pieces of data in two different files, where it's okay if the data in file A is "newer" (in a versioning sense, not a timestamp sense) than the corresponding data in file B, but the opposite doesn't hold. So if you have another program writing that data it will write first to A, and then to B. The program reading this *must* then read the files in the correct order (B then A, to ensure the data from A is always newer or at the same "version" as the data in B).
That's nonsense. Because what happens if your program reads A while the other program is writing to A, or reads B just after the other program has written to A, but before it has written to B?
As I said before, you cannot make any guarantees in the presence of interference, _with or without_ commuting. So any sensible effects system will assume no interference (perhaps with unsafeXXX functions for when you're OK with shooting yourself in the foot).
Anytime you talk to the outside world, there may be implicit ordering that you need to respect, so I really think that needs to be serialized. Of course, there may be things in the IO monad that doesn't talk to the outside world that could be commutative.
If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non-overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. The IO monad is a poor man's solution to the problem of effects.
Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
