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

Keean Schupke k.schupke at
Tue Nov 23 04:39:38 EST 2004

Adrian Hey wrote:

>I guess you mean the usual handle based approach, but this makes no
>sense at all for a Haskell interface to some *unique* stateful resource
>(eg. a piece of raw hardware or "badly designed" C library). The handle
>is a completely redundant argument to all interface functions (there's no
>need identify which thing is being referenced because there is only one).
Hopefully my last post laid the raw hardware device example
to rest... It really is not necessary if coding a 'pure haskell'
driver for some hardware as part of a Haskell OS. If the OS
is not in Haskell your second example reduces to your first,
if the OS is not serialising devices access we are just
talking about interfacing with a badly written C library again.

>This is one situation, but certainly not the only possible one. You have
>the same problem with interfacing to any unique stateful resource (or
>even if you have a multiple but finite supply of these resources).
No you don't... Most devices have registers, those registers contain
values, you can inspect those values to see if the device has been
initialised. You can then write a guard on the initialisation that really
checks if the device has (or hasn't) been initialised rather than rely 
on some
'shadow' copies in RAM.

> Huh? Top level TWIs are just part of the initial world state (as seen
>by main). We can argue about whether or not they are needed, but their
>existence surely doesn't make the situation any worse than it already
The IO monad passes its state around, it is just hidden. This is not
like implicit parameters. So main is _passed_ RealWorld as an
argument, and returns RealWorld, just like the state monad:

    data State a = State (s -> (s,a))

Hides the passing of the state...

>I have a feeling that those folk who think they don't need it are
>those who enjoy the luxury of doing all their IO via pre-supplied
>"Haskell user friendly" libraries and haven't given much thought
>to how these libraries actually work or how they could be
>implemented in Haskell if they didn't already exist (without using
>the unsafePerformIO hack of course). 
No, if that were the case I would be suggesting we can do
without unsafeInterleaveIO... but unfortunately it seems
necessary to me.


More information about the Haskell mailing list