[Haskell-cafe] Global Variables and IO initializers
Ben Rudiak-Gould
Benjamin.Rudiak-Gould at cl.cam.ac.uk
Mon Nov 8 21:18:51 EST 2004
I think the broad issue is that there are many different levels of the
system at which something can be global: a module, a thread, a process,
a user, a computer, a network segment, the internet, the universe, etc..
If your model of a concept is more global than the concept itself, you
lose flexibility. If your model is less global than the concept, you get
cache-coherency problems.
The global variables we're talking about here are global to a single
invocation of a Haskell program [*] [**]. The only concepts which are
appropriately modeled by such globals are those whose natural scope is a
single invocation of a Haskell program. Are there any?
Adrian Hey's example of a badly-written C library is one. But I agree
with Robert Dockins that such cases are better solved in C than in Haskell.
(stdin,stdout,stderr) seem to naturally have this scope (assuming you
don't use freopen). There needs to be only one Handle created for each
of these because otherwise the buffering won't work properly. Global <-
initializers seem like the right thing here.
Are there any others?
-- Ben
[*] Adrian Hey has argued that "global" variables aren't really global.
I think he's talking about hiding them through module scoping. What I
mean by global is different: something is global at a particular level
of the system if there's only one instance of it at that level.
[**] Wouldn't it make sense to support thread-local global state also,
if we're going to support process-local global state?
More information about the Haskell-Cafe
mailing list