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.
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
