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

[George Russell]

Benjamin Franksen wrote (snipped):
 > Doesn't that run contrary to Adrian Hey's "oneShot" example/requirement?

Remind me again what Adrian Hey's "oneShot" example/requirement is ...

 > 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?
This seems to me as unnecessary as asking for which memory location it has.
Provided the no-longer-global variables act as if they were global within
their own universe, there is no problem.   The withEmptyDict operator
I provide gives you a new universe where everything starts from scratch.

It seems to me you have a much bigger problem when you force everything to
have global variables, and then want to run multiple copies of a program,
only to have them clobber each other's variables.

 > 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?

Consider Data.Unique implemented over lots of processors.  If you had a single
IORef managed by a single processor used to generate new unique identifiers,
there is the danger that that processor will become a bottleneck for the whole
system.  Much better to have a thread-local or processor-local IORef which generates
new identifiers, which you then prepend with a processor tag.


Me (snipped):
 > It is, but I'm not sure if it can be avoided without using stuff not in
 > the standard libraries.

Ben:
 > What non-standard libraries have I used (that you don't)?
OK, but you have to test every element of the dictionary with fromDynamic until
you find one with the type you want, which is not a good idea if the dictionary
is big.  My implementation is equally inefficient now (because TypeRep's have
no Ord), but if TypeRep's had Ord or a hashing function (both would be very
easy to provide from GHC's implementation) I could make my implementation
efficient very easily, while you'd have to completely rewrite yours to get
the same effect.