<br><br><div class="gmail_quote">On Fri, Aug 14, 2009 at 9:41 PM, John A. De Goes <span dir="ltr"><<a href="mailto:john@n-brain.net">john@n-brain.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div><div>Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. </div>
</div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div><div>Of course, there may be things in the IO monad that doesn't talk to the outside world that could be commutative.</div>
<div> </div></div><br clear="all"><br>-- <br>Sebastian Sylvan<br>