Hello,
Well it seems like you haven't started another flame war (yet :-).
Indeed; I am a little surprised to hear the silence.
I'm afraid I haven't properly understood your proposal, because I don't have much time right now. It seems to be a bit like George Russels proposal (aka "execution contexts").
Somewhat. However, execution contexts don't have the initializer concept.
Personally I have never felt the need for thread local state, but I have often needed to use the unsafePerformIO hack to create *unique state* for API's that are both sane from a users point of view and are also invulnerable to accidental or malicious state "spoofing". So thread local state isn't really what I want (it's a sure way to guarantee that spoofing will occur :-)
You seem to indicate that this is still possible with your scheme, but I'm not sure of the details.
If you declare a thread-local in a module but don't export it, then you have exclusive control over what happens to that thread-local. You set the initializer and no one else can touch it. If you set an initializer that copies parent values and never write to the cell, you effectively have a variable that is set exactly once at program start. The only way to alter this from outside the module is to use the "clearBank" primitive, which resets all thread-locals to empty. It may be that this primitive is too dangerous to include. On the other hand, I'm not convinced that absolutely unique state is that great. Suppose I want to run multiple copies of my Haskell OS in an emulator so I can test the TCP/IP stack I just wrote? I'll need some way to keep the "unique" state for each OS separate.
Maybe you should put all this on the wiki page. I'd like to see how/if you could implement the hypothetical device driver API I put there, or even just use the "oneShot" function or similar at the top level.
I've attached a hypothetical implementation in the proposed syntax.
Regards -- Adrian Hey
Robert Dockins