Adrian Hey wrote:
Also, we don't want different threads to have their own versions of these. They are for use in situations where you need to represent state associated with a genuinely unique resource (eg top level stateful C library or hardware IO device)
So in such situations it's both unnecessary and downright dangerous to provide a "newResourceState" constructor and pass this to releted IO routines as a parameter. But in the absence of such a constructor, how can the state exist at all, unless one allows top level <- bindings? This is the problem I think we're trying to solve with the top level <- proposal.
I disagee - Allowing unique state is a mistake in my opinion. I want Haskell to be the operating system - how can I do this if I cannot create new process contexts. Also how can I deal with multiple pieces of hardware that are unique? The problem with your proposal is that resources are finite, not unique. You need a solution that will allow N drivers to run N pieces of hardware - one is just a special case like when your machine only has one serial port. Some machines have two, or more... (yet the drivers are written to only handle a single device, and will be initialised multiple times once for each device) Look at how Linux scans the hardware at boot time and initialises a driver for each device it finds... that means that each driver is parameterised by the IO address of the device, and can be initialised multiple times. When an OS boots it runs an initialisation routine (the 'main' of the kernel) This is just like the main in a Haskell program - there is no need for anything to be initialised _before_ main runs... The init routine calls init on each device driver in turn, finally handing control over to the scheduler, which loads the 'init' program and that starts all the user programs. I don't see any calls for unique guarantees here... Keean. Keean.