Here is a naive and dirty implementation. The largest problem is that TypeRep is not in Ord. An alternative approach using Dynamic would be possible, but I like the connection between the key and the associated type.
http://www.cs.helsinki.fi/u/ekarttun/haskell/TLS/
Not optimized for performance at all.
You've redefined 'fork'. If I want a library which works with other libraries, that will not be an option. The original purpose of my posting to this thread was to ask for two standard functions which would let me define thread-local variables in a way which is interoperable with other libraries, to the same extent as 'withArgs' and 'withProgName' are.
I also forgot to mention that if you hold on to a ThreadId, it apparently causes the whole thread to be retained. Simon Marlow explained this on 2005/10/18: m> One could argue that getting the parent ThreadId is something that m> should be supported natively by forkIO, and I might be inlined to agree. m> Unfortunately there are some subtleties: currently a ThreadId is m> represented by a pointer to the thread itself, which causes the thread m> to be kept alive. This has implications not only for space leaks, but m> also for reporting deadlock: if you have a ThreadId for a thread, you m> can send it an exception with throwTo at any time, and hence the runtime m> can never determine that the thread is deadlocked so it will never get m> the NonTermination exception. Perhaps we need two kinds of ThreadId: a m> weak one for use in Maps, and a strong one that you can use with m> throwTo. But then building a Map in which some elements can be garbage m> collected is a bit tricky (it can be done though; see our old Memo table m> implementation in fptools/hslibs/util/Memo.hs). So this is another problem with your implementation, and another reason why I want TLS support in the standard libraries. Frederik -- http://ofb.net/~frederik/