[Haskell-cafe] ACIO versus Execution Contexts

[Keean Schupke]

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.