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.
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
