[Haskell-cafe] Re: [Haskell] Re: Global Variables and IO initializers

[Benjamin Franksen]

On Thursday 25 November 2004 10:02, you wrote:
>  > This is funny. When I got no immediate reaction from you, I started
>  > implementing it myself. I ended up with something similar. It has less
>  > features but is also a lot simpler. This is the interface:
>  >
>  > initGlobal :: Typeable a => a -> IO ()
>  > getGlobal :: Typeable a => IO a
>
> Your implementation is probably much simpler than mine because you don't
> implement withEmptyDict.  I'm really quite keen about withEmptyDict,
> because one of the MAJOR conceptual problems I have with unsafePerformIO
> global variables is that you only get one universe, corresponding to the
> Haskell program. There shouldn't really be a single "the Haskell program" 
> anyway;

Doesn't that run contrary to Adrian Hey's "oneShot" example/requirement?

> imagine something like GHC or an operating system written in 
> Haskell which run sub-systems which require their own global variables.

Well, that's indeed one major problems with global variables. Sure, you can 
try to solve it with multiple dictionaries, but that makes understanding what 
a certain part of the program does even harder. How do I find out what 
dictionary a write or read to a (no longer global) variable refers to?

Furthermore, I have great difficulty in understanding why different threads 
need different dictionaries. Could you explain why this is useful, or rather, 
more useful than a global single dictionary?

It reminds me of the usual "thread-local" variables that are offered by most 
systemlevel thread libraries. I think they put them in there so that they can 
easily port non-reentrant libraries (i.e. ones that use global variables 
internally) to a multi-threaded setting without changing their APIs. This 
approach leads to libraries that are extremely inconvenient and dangerous to 
use. Their existence is one of the reasons why I have been arguing so much 
against global variables.

>  > Storing (TypeRep,Dynamic) pairs is redundant, since Dynamics already
>  > contain their own TypeRep (that is how they are made to work).
>
> It is, but I'm not sure if it can be avoided without using stuff not in
> the standard libraries.

What non-standard libraries have I used (that you don't)?

Ben