<br><br><div class="gmail_quote">On Sun, Aug 16, 2009 at 2:50 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><div class="im"><div>On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:</div></div><blockquote type="cite"><div class="gmail_quote"><div class="im">On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes <span dir="ltr"><<a href="mailto:john@n-brain.net" target="_blank">john@n-brain.net</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex"><div>You must think I'm arguing for some kind of low-level analog of C, augmented with an effect system. I'm not. You can't do that. </div>
</blockquote><div class="im"><div><br></div><div>No, I don't. I think you're arguing for making access to mutable state commutative. Are you not?</div></div></div></blockquote><div><br></div><div>There are many cases when mutation to state _is_ commutative. I can't argue that certain operations are _always_ commutative without talking about the language.</div>
<div><br></div><div>Pretend I'm arguing for a mostly functional language and effect system that maximize the opportunities for parallelizing code.</div><div class="im"><br><blockquote type="cite"><div class="gmail_quote">
<div> I'm not saying you shouldn't parallelise them in very specific circumstances *where it's safe*, I'm just saying that you shouldn't assume that it's safe unless you know it is. If you want to do a transformation that's unsafe in general, but safe in a specific circumstance, then of course, go ahead!</div>
<div>To my reading it seems like you're arguing that memory/file access should *always* be considered commutative though, which is what I'm objecting too.</div></div></blockquote><div><br></div></div><div>In the right language, many times of memory (and possibly file) operations _always_ commute. In the wrong language, they _sometimes_ commute or _never_ provably commute. I'm not arguing for the assumption in any language where it is false.</div>
</div></div></blockquote><div><br></div><div>Well now I'm confused. Earlier you said:</div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">"In the case of a file system, you can commute two sequential reads from two different files. This has no effect on the result of the computation, assuming no interference from other programs -- and if there _is_ interference from other programs, then guarantees go out the window, _with or without_ commuting."</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">It's the "assuming no interference form other programs" that bugs me, because when you're reading outside data you kind of have to assume that there *is* outside interference because you can't really protect yourself against it. Furthermore, that "interference" is often more like cooperation/communication so you're actually *counting* on "outside interference".</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse; ">E.g. consider durable storage that have to survive random reboots etc., I'm sure there are quite a few very carefully considered sequential steps that need to happen in just the right order to get a consistent view of the data when you read it back in.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse; "><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">That earlier quote seems to imply that you're arguing for just treating all file reads as commutative and just ignoring that this is an unsafe assumption. If you no longer think this then I guess we're in agreement. </span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">My point is that *if* there is any chance for outside access to anything you're reading, then ordering *does* matter. This is the case for file reads, and may be the case for memory reads. For the latter the compiler could *potentially* figure out when memory can't be touched by other threads and make them commute, but I still think the semantics for mutable code should be sequential (since it unifies the two scenarios), and then the compiler might make them commutative in scenarios where it's guaranteed to be safe.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">For file reads, I don't think there's a way of knowing that two file reads are independent, especially since this dependency might live *outside* the program (e.g. the dependency might only exist for the human reading the output of the program). So really, if there's any chance something else might touch your data, the only reasonably safe way to deal with it is to enforce sequentiality.</span></font></div>
<div><br></div></div>-- <br>Sebastian Sylvan<br>