On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes <j...@n-brain.net> wrote:
> On Aug 15, 2009, at 4:59 PM, Sebastian Sylvan wrote: > > >> Your point about safety in C has no relation to safety in a functional >> language with a sophisticated effect system. >> >> I'm sorry, but I think it does. You're advocating that modifications to >> mutable state shouldn't have sequential semantics, >> > > 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. No, I don't. I think you're arguing for making access to mutable state commutative. Are you not? > In such conditions, multiple sequential writes can be safely parallelized, > in addition to a host of other optimizations. 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! 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. > I'm pointing out that this is the case today in C on many CPUs and it's a >> royal pain to work with in practice (causing many almost-impossible-to-debug >> crashes). I would not want functional languages to adopt something that's >> proven to be insanity-inducingly difficult to use. >> > > Please don't ever bring up C again. You can't do anything interesting in C. I bring up C until you can explain how what you're suggesting is any different from the current state in C w.r.t. the ordering of memory access. >From what you've said so far I can't see how it is, and it would be instructive to look at the problems with the approach you're advocating since we're dealing with its pitfalls *today* in the real world. -- Sebastian Sylvan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
