[Haskell-cafe] Execution Contexts
benjamin.franksen at bessy.de
Sat Nov 27 15:10:21 EST 2004
On Saturday 27 November 2004 17:10, you wrote:
> On Sat, 27 Nov 2004, Benjamin Franksen wrote:
> > An execution context is a mutable finite map from types to (monomorphic)
> > values. Each IO action implicitly carries exactly one such map and by
> > default passes it on to the actions that follow.
> Execution contexts sound a good description of them. Building on your
> recoding of this, if you have top-level declarations of newMVar / newIORef
> then how much of this can you do by just keeping a dictionary in a global
> This should certainly save some of the StateT plumbing; and
> such declarations are safe, becuase they are affine central (see
> http://groups.google.com/groups?selm=fa.doh68b9.96sgjd%40ifi.uio.no )
I like your definition of ACIO and I think it is sound (I have also suggested
I would think that with ACIO we have a nice mathematical characterization for
the IO actions that would be "safe" even at the top-level. ("Safe" meaning
mainly that we do not open a can-of-worms with regard to execution order.) I
don't know how easy or hard it is to prove of a certain IO action that is in
fact in ACIO.
However, monadic execution contexts don't need any safety proofs, because they
are purely functional. With modest support from the compiler they could be
implemented quite efficiently. And they would solve almost all problems for
which global variables have been used or proposed as a solution. To be more
precise, they would solve all those problems, provided you replace any
reference to "the whole program" by "a certain execution context". I think
this would be good enough for almost all applications.
> > A function is provided to (implicitly) create a new mapping and run a
> > given IO action with the new mapping as its execution context, instead
> > of the default one.
> Update the global MVar, do the IO, then reset it?
This breaks down as soon as the IO action does a forkIO. This breakdown is one
of the reasons I dislike global variables so much. Sure, you can find a way
to code around this special probem.(*) But the fact that you have to
(explicitly take concurrency into consideration) doesn't bode well for global
One of the nice features of (monadic) execution contexts is that they are
automatically protected from such problems, without taking any special
> > I am almost sure that even the trick of indexing the dictionary via
> > types (and thus the dependency on Data.Typeable and ghc extensions) can
> > be avoided with a little more effort.
> Another global MVar to issue a sequence of unique index keys?
Maybe this is possible. But I'd rather have a library that depends on Dynamics
(plus some compiler support) than a highly controversial new language
(*) You'd probably need a hack like using ThreadIds to identify the IO action
being run under the new context, see George Russel's implementation.
More information about the Haskell-Cafe