[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