Re: [Haskell] Re: Global Variables and IO initializers
Benjamin Franksen wrote (snipped):
Doesn't that run contrary to Adrian Hey's "oneShot" example/requirement?
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
Remind me again what Adrian Hey's "oneShot" example/requirement is ... 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.
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
Ben: the same effect.
[for the 4th time moving this discussion to cafe] On Friday 26 November 2004 08:39, you wrote:
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 ...
http://www.haskell.org//pipermail/haskell/2004-November/014766.html
[...]
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.
I see. Note that currently there exists no Haskell implementation that is able to make use of multiple processors. See http://research.microsoft.com/Users/simonpj/papers/conc-ffi/conc-ffi.ps Having read http://www.haskell.org//pipermail/haskell-cafe/2004-November/007666.html again, as well as your comments above, I tend to agree that withEmptyDict may indeed be useful. However, the situations you describe are somewhat special. They can and should be handled by explicitly calling withEmptyDict. I still can't see any reason why each single Haskell thread should have its own searate dictionary. Contrary, since it is common to use forkIO quite casually, and you expect your actions to do the same thing regardless of which thread calls them, this would be disastrous. IMO GlobalVariables.hs shouldn't be aware of threadIds at all.
What non-standard libraries have I used (that you don't)?
[...explanation...]
I see. Thanks for the explanation. Ben
On Friday 26 November 2004 14:12, Benjamin Franksen wrote:
I still can't see any reason why each single Haskell thread should have its own searate dictionary. Contrary, since it is common to use forkIO quite casually, and you expect your actions to do the same thing regardless of which thread calls them, this would be disastrous. IMO GlobalVariables.hs shouldn't be aware of threadIds at all.
I think I misunderstood your proposal (GlobalVariables.hs). It seems to do what I would expect, if your version of forkIO is used. I thought by inheriting the dictionary you meant working on a new copy, but it does in fact mean using the same dictionary. Sorry for the confusion. Ben
On Friday 26 November 2004 08:39, George Russell wrote:
Benjamin Franksen wrote (snipped):
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.
[completely off-topic but anyway:] This is yet another incidence where Robert Will's ByMaps would be very useful: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/principles.html#bymap I am quite astonished that apparently none of the data structure library projects have taken up the idea. Ben
On Friday 26 November 2004 08:39, you wrote:
Benjamin Franksen wrote (snipped):
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.
[completely off-topic but anyway:] This is yet another incidence where Robert Will's ByMaps would be very useful: http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/principles.html#bymap I am quite astonished that apparently none of the data structure library projects have taken up the idea. Ben
participants (2)
-
Benjamin Franksen -
George Russell