<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Aug 14, 2009, at 9:34 PM, Sebastian Sylvan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes <span dir="ltr"><<a href="mailto:john@n-brain.net">john@n-brain.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> 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.</blockquote> <div><br></div><div>I'd like to point out that this relaxation of sequencing for memory operations is already in effect in C on many CPUs. Even though you write things sequentially, it doesn't actually happen sequentially unless you explicitly say so with memory barriers. This causes massive head-aches and horrible bugs that are almost impossible to track down whenever you actually do depend on the order (usually in multi-threading scenarios, e.g. lockless data structures).</div></div></blockquote><div><br></div>That's because C has no effect system and is too low-level for an effect system. That's no argument against one in a high-level language similar in syntax to Haskell.</div><div><br><blockquote type="cite"><div class="gmail_quote"> <div>The point is, the safer option is to enforce a sequential model (like Haskell does), since that way you can always rely on ordering even if you don't even realise you need to, and there's plenty of practical experience indicating that the other option (explicit barriers to indicate when something isn't commutative) is sheer madness.</div></div></blockquote></div><br><div>Your point about safety in C has no relation to safety in a functional language with a sophisticated effect system. Haskell enforces a sequential model not because it's safer (it's NOT), but because it's simpler and because it's the best Haskell monads can do.</div><div><br></div><div>Unfortunately, it doesn't fly in a world with dozens of cores.</div><div><br></div><div><span class="Apple-style-span" style="font-size: 12px; "><div>Regards,</div><div><br></div><div>John A. De Goes</div><div>N-Brain, Inc.</div><div>The Evolution of Collaboration</div><div><br></div><div><a href="http://www.n-brain.net">http://www.n-brain.net</a> | 877-376-2724 x 101</div></span></div></body></html>