DDC compiler and effects;
better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
John A. De Goes
john at n-brain.net
Fri Aug 14 22:55:01 EDT 2009
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.
John A. De Goes
The Evolution of Collaboration
http://www.n-brain.net | 877-376-2724 x 101
More information about the Haskell-Cafe