Re: ACIO versus Execution Contexts
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.
On Tuesday 30 Nov 2004 12:53 pm, George Russell wrote:
Adrian Hey wrote (snipped):
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.
Well it's true there probably aren't many people actually writing hardware device drivers in Haskell at the moment, but it is something that should be possible to do safely. But the case of C libraries is far more typical at the moment I think. Hardly any (like none that I have ever used) can be safely used without precautions which require top level mutable state, one way or another.
I think Keean and Lennart have already said most of what I have to say here.
Oh no, not you as well :-). As I observed in an earlier post, you still have the same basic problem even if you a multiple but finite supply of these resources. The problem is slightly different, but is still insoluble without top level TWIs. Keean and Lennart are just hiding the problem in a hypothetical "operating system" which is simply assumed to be correct (it just doesn't do any of the dangerous things that might otherwise be done). I don't dispute that top level TWIs are arguably unnecessary, in the sense that there's no *program* that can be written with them that couldn't be written without them (in principle). The issue is *modularity*. Without top level TWIs there are certain safety guarantees that I cannot make from within my module. Instead I have to "beg" for safe use from outside my module. Begging a hypothetical "operating system" doesn't really help much. Regards -- Adrian Hey
Adrian Hey wrote:
The issue is *modularity*. Without top level TWIs there are certain
safety guarantees that I cannot make from within my module. Instead I have to "beg" for safe use from outside my module. Begging a hypothetical "operating system" doesn't really help much.
And I am arguing that the library is not the appropriate enitity to enforce this uniqueness, and that should I have multiple of these 'unique' resources available, I should be able to initialise the library in two contexts at once. It seems a bad assumtion to assume that _all_ systems will only have one of these whatevers. Keean.
participants (3)
-
Adrian Hey -
George Russell -
Keean Schupke