[Haskell-cafe] ACIO versus Execution Contexts

George Russell ger at informatik.uni-bremen.de
Mon Nov 29 08:19:59 EST 2004


I think it would be nice to summarise the current state of play.  This really
needs to be a WiKi.

Ian's ACIO proposal

    http://www.haskell.org//pipermail/haskell-cafe/2004-November/007680.html

seems in fact to achieve much the same as the proposal I originally posted
to

    http://www.haskell.org//pipermail/haskell/2004-November/014894.html

and which Benjamin Franksen has explained and simplified here

    http://www.haskell.org//pipermail/haskell-cafe/2004-November/007691.html

You can in fact do much the same with both.  With Haskell 98, Data.Dynamic
and ACIO and, if your implementation has concurrency at all, thread identifiers,
I can implement execution contexts.  On the other hand ACIO allows you to
create variables with top-level declarations such as

    x <- newIORef 0

which can then be accessed in a pure way.  With Execution Contexts you cannot
do this; you would instead need a function  getX :: IO (IORef Int) which
would get the global variable x.  In practice I don't think this distinction
very important, since there's not much you could do with x except
using the IO monad.

Disadvantages of execution contexts
-----------------------------------

1.  You are only allowed one value of each type in an execution context.
Thus it is dangerous to try to use a global value of type (IORef Int);
people would have to be advised to create a special newtype for each value.

2.  They are likely to be less efficient than just allowing <- declarations
at top level.  Certainly they are in my implementation.  The vast majority of
this inefficiency can be eliminated by using hash tables, but you can't
escape doing at least one hash-table lookup each time you want to access a
global value.  The bare minimum then would be one division by a constant
followed by an indirection.

3.  In a concurrent system, you also need forkIO to be modified, so that
you can work out which execution context applies to you.

Disadvantages of ACIO
---------------------

1.  The ACIO proposal preserves one bad feature of unsafePerformIO, namely
that you only have one "execution context".  You cannot for example run
two copies of the same program simultaneously, since they will clobber
each other's global variables.

2.  I don't know exactly how ACIO is to be implemented, but it looks as if
at the least it requires an extension to the Haskell syntax.

3.  I think that if the ACIO proposal were implemented, it would in any case be
a good idea to implement execution contexts or something like them on top of
it, so that people can create initialisation actions which do other things than
the very strict subset allowed as ACIO actions.

Questions
---------

1.  Is there anything people would like to do with ACIO for which execution
contexts would not be practical?
2.  Which if either of the proposals would the gods responsible for implementing
Haskell compilers favour?





More information about the Haskell-Cafe mailing list