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. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
