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

[Sebastian Sylvan]

On Sat, Aug 15, 2009 at 3:55 AM, John A. De Goes <john at n-brain.net> wrote:

> On Aug 14, 2009, at 8:21 PM, Sebastian Sylvan wrote:
>
>  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).
>>
>
> That's nonsense. Because what happens if your program reads A while the
> other program is writing to A


Depends on the file system. For example, the file could be locked so you
would just block. Or the file system might be transactional. I used files as
an example, the point wasn't to get bogged down in exact semantics of
concurrent access - assume all reads/writes are atomic (or can be viewed as
such from the apps POV) for the purposes of discussion.


> , or reads B just after the other program has written to A, but before it
> has written to B?


This is precisely the scenario that would be legal in that case. You'd end
up with data from A that's newer than B, which we said was okay, but for
some app-specific reason the opposite is *not* okay. In order for you not to
crash you *have* to make sure you read from B first, because otherwise you
could read from A right before it's updated, and then read B right after
both A and B have been updated which means B is now newer than A and your
program goes boom.

 The point is that the ordering of reads are not arbitrary.


> As I said before, you cannot make any guarantees in the presence of
> interference, _with or without_ commuting.


That's a separate issue. The problem is that if you *do* depend on outside
"interference", then the sequence of operations matters.


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