DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)

[Sebastian Sylvan]

On Sun, Aug 16, 2009 at 2:50 PM, John A. De Goes <john at n-brain.net> wrote:

> On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote:
>
> On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes <john at n-brain.net>
>  wrote:
>
>> 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?
>
>
> 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.
>
> Pretend I'm arguing for a mostly functional language and effect system that
> maximize the opportunities for parallelizing code.
>
>  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.
>
>
> 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.
>

Well now I'm confused. Earlier you said:
"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."

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".
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.

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.
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.

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.

-- 
Sebastian Sylvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090816/fc9275bb/attachment.html