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

[John A. De Goes]

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, or reads B just after the other  
program has written to A, but before it has written to B?

As I said before, you cannot make any guarantees in the presence of  
interference, _with or without_ commuting. So any sensible effects  
system will assume no interference (perhaps with unsafeXXX functions  
for when you're OK with shooting yourself in the foot).

> Anytime you talk to the outside world, there may be implicit  
> ordering that you need to respect, so I really think that needs to  
> be serialized.
> Of course, there may be things in the IO monad that doesn't talk to  
> the outside world that could be commutative.

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. The IO monad is a poor man's solution to  
the problem of effects.

Regards,

John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration

http://www.n-brain.net    |    877-376-2724 x 101