[Haskell-cafe] Re: ACIO versus Execution Contexts

[George Russell]

Adrian Hey wrote (snipped):
 > I've been looking at your global variables library.

Thanks.
> In particular, the purpose of top level <- bindings IMO is *not* to
> provide "global variables" (though they could be abused this way).
> If you consider the example..
> 
>  userInit <- oneShot realInit
> 
> ..the top level MVar created is not global. It doesn't even scope over
> an entire module, it's buried in a closure. This kind of use would be
> pretty typical I think. Even when you do have top level IORefs (or
> more complex mutable data structures) scoping over an entire module,
> generally they won't be exported by that module. Instead access is
> strictly limited to a few carefully defined IO actions, and these
> are exported.

I think you must mean by "global variable" something different to what
I mean by "global variable".  It is precisely such uses as you describe
above which I would anticipate being supported by the Execution Contexts
proposal.  Of course good structured programming would hide a module's use
of execution contexts or top-level variables.

 > Also, we don't want different threads to have their own versions of
 > these.

There seems to have been some confusion on this point, so I should make
it clear that by default, with my proposal, threads *do*not* each have
their own versions of the variables.  This only happens if you explicitly
create a new execution context and run an action within it; that action,
and the threads it forks off, will then use the new execution context.

 > They are for use in situations where you need to represent
 > state associated with a genuinely unique resource (eg top level
 > stateful C library or hardware IO device).

In my experience this is only true quite rarely.  I think Keean and Lennart
have already said most of what I have to say here.