Hi Simon, It is good that you support thread-local variables.
I have initialized a wiki page: http://haskell.org/haskellwiki/Thread_local_storage The main difference between my and your proposals, as I see it, is that your proposal is based on "keys" which can be used for other things. I think that leads to an interface which is less natural. In my proposal, the IOParam type is quite similar to an IORef - it has a user-specified initial state, and the internal implementation is hidden from the user - yours differs in both of these aspects. > * I agree with Robert that a key issue is initialisation. Maybe it > should be possible to associate an initialiser with a key. I have not > thought this out. I still don't understand this, so it is not mentioned on the wiki. > * A key issue is this: when forking a thread, does the new thread > inherit the current thread's bindings, or does it get a > freshly-initialised set. Sometimes you want one, sometimes the other, > alas. I think the inheritance semantics are more useful and also more general: If I wanted a freshly-initialized set of bindings, and I only had inheritance semantics, then I could start a thread early on when all the bindings are in their initial state, and have this thread read actions from a channel and execute them in sub-threads of itself, and implement a 'fork' variant based on this. More generally, I could do the same thing from a sub-thread of the main thread - I could start a thread with any set of bindings, and use it to launch other threads with those bindings. In this way, the "initial" set of bindings is not specially privileged over intermediate sets of bindings. > On the GHC front, we're going to be busy with 6.6 etc until after ICFP, > so nothing is going to happen fast -- which gives an opportunity to > discuss it. However it's just infeasible for the community at large to > follow a long email thread like this one. My suggestion would be for the > interested parties to proceed somewhat as we did with packages. > (http://hackage.haskell.org/trac/ghc/wiki/GhcPackages) I have put a page on the wiki summarizing the thread. However, I want to say that I think that email is a better medium for most ongoing discussions. (I'm not sure if I may have suggested the opposite earlier) For those who are not interested in the discussion, it should be easy in most mail readers to ignore or hide a long thread, or to skip to the very end of it to get a rough idea of where things stand. I think it is a good idea to have proposals on a wiki, though, so that the product of all agreed-upon amendments and alterations can be easily referred to. When discussions happen on a wiki, though, they often take the same threaded form as email discussions (see Wikipedia) - but, they are seen by fewer interested people, and the interface is clumsier (for instance, I can subscribe to email notification when a wiki page changes - thanks to whomever finally made this possible on haskell.org, by the way - but I have to read the updated version to figure out whether the modification was replying to me or another poster; whereas my mail reader clearly flags messages where I appear in the recipients list). Frederik -- http://ofb.net/~frederik/ _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
