[Haskell-cafe] Re: ACIO versus Execution Contexts
ger at informatik.uni-bremen.de
Tue Nov 30 07:53:17 EST 2004
Adrian Hey wrote (snipped):
> I've been looking at your global variables library.
> 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
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.
More information about the Haskell-Cafe