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.
No you don't... Most devices have registers, those registers containThis 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).
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 is.
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.
Keean. _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell