Hmmm, my point (perhaps I wasn't clear), is that different effects
have different commutability properties. 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.
Monads are an insufficient structure to capture the fine semantics of
effects. Something more powerful is needed. And in general, the way
effects combine and commute is quite complicated and needs to be baked
into the effect system, rather than being the responsibility of a
lowly developer.
Regards,
John A. De Goes
N-Brain, Inc.
The Evolution of Collaboration
http://www.n-brain.net | 877-376-2724 x 101
On Aug 13, 2009, at 12:24 PM, Sebastian Sylvan wrote:
On Thu, Aug 13, 2009 at 2:19 PM, John A. De Goes <j...@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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
