Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

[Adrian Hey]

On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote:
> Is this a joke?

No.

> Seriously if you writing the OS in haskell this is trivial,
> you fork a thread using forkIO at system boot to maintain the driver,
> all 'processes' communicate to the thread using channels, the thread
> maintains local state (an IORef, or just a peramiter used recursively)
>
>     myDriver :: (Chan in,Chan out) -> State -> IO State
>     myDriver (in,out) state = do
>        -- read commands from in
>        -- process commands
>        -- reply on out
>        myDriver (in,out) new_state

How does this solve the problem we're talking about (namely preventing
the accidental creation of multiple processes all of which believe they
are "the" device driver for a particular unique resource)?

I take it we can't expose myDriver to the world at large, so what the
world at large sees must be just the unique channels to communicate
with one myDriver (which is forked only once somewhere outside main).
I can think of three ways of allowing the world at large to see the
channels.

1- Have them as top level TWI's. I guess you're not in favour of that.
2- Have getChannels :: IO (Chan in,Chan out) instead. But this buys you
   no extra safety, and there's still the problem of how to implement
   getChannels if we're not allowed top level TWI's.
3- Have the in and out channels of this and every other periheral passed
   as an explicit argument to the user main. Yuk!, highly unmodular IMO,
   not mention having the type of main depend on what devices were available.  

Again it would seem an appropriate implementation of getChannels would
be a top level ..

getChannels <- oneShot $ do inChan  <- newChan
                            outChan <- newChan
                            forkIO $ myDriver (inChan,outChan) state0
                            return (inChan,outChan)

But of course this is so evil it's not worth further consideration :-)

Regards
--
Adrian Hey