A general point on top-level TWIs. It occurs to me that all variables are local to something (function, object, thread, process, machine, network, world...). I think it is an error to limit Haskells domain. If we allow unique per process variables (top-level TWI's) we limit our level of abstraction to a process - haskell cannot dispatch processes beacuse it cannot handle the multiple process contexts required. All the attempts at modelling execution contexts therefore seem a better solution than top-level TWIs which limit us to a single process world model. It seems the real world is an infinitely deep nesting of abstractions, so uniqueness is always relative to its context. Using the object model, we can have a process object, this object can ensure uniqueness of values within the context of a process - which is what Adrian wants. However if we want uniqueness at the next level, say the per CPU level, then a CPU object is the relavent context. It seems to me the object model fits perfectly, and what people are trying to do is turn modules into primitive objects complete with data-hiding and constructors (top-level TWIs)... However modules cannot be nested so the model breaks down, and we end up needing first-class modules anyway. Of course objects can be modeled another way (see http://www.cwi.nl/~ralf/OOHaskell) using the HList library... The syntax is simple enough, but would still benefit from a little sytactic sugar (hopefully to be providied by template-haskell, but this part is a work in progress). So in conclusion, it seems to me that that objects in Haskell solve all the problems that top-level TWIs solve, and still allow encapsulation and multiple 'process' contexts to be handled by the RTS. So use them! Sorry for the rambling explanation and shameless promotion of HLists... Keean.