On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes <john at n-brain.net> wrote:
> What if you have another program, written in C or something, that
> monitors a file for changes, and if so changes the contents of another file?
> Surely to catch that you must mark *all* file system access as
> "interefering"? Even worse, another program could monitor the state of a
> file and conditionally disable thet network driver, now file access
> interferes with network access.
>>> A compiler or runtime system can't know about these kinds of things --
> unless perhaps you push the effect system into the operating system
> (interesting idea). The best you can do is ensure the program itself is
> correct in the absence of interference from other programs
>
I think the best you can do is make sure any code which is vulnerable to
such interference won't be subject to unsafe transformations (like changing
the order of evaluation).
So I do think pretty much anything that relies on the outside world needs to
go into one big effects "category" so the compiler/runtime will "stay out"
and let the programmer explicitly define the ordering of those operations,
precisely because the compiler has no way of knowing anything about what
kind of assumptions are in effect.
--
Sebastian Sylvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090813/137a53de/attachment.html