[Haskell-cafe] Re: [Haskell] Top Level <-

[Adrian Hey]

Lennart Augustssom wrote:
> Since at some point you have to interface with the hardware you are 
> forced to obey whatever convention is used for interrupts etc. At that 
> point you may very well have to use global variables. But you can 
> quickly abstract away from that in stay in the safe land without globals.

BTW, did you notice that the non-hosted driver API example I put on the
wiki page doesn't use "globals" either :-) The two device handles are
at the top level (are "globals" as you would say), but the driver
code takes these as an argument so doesn't care if they're top
level or not.

If I don't have the device handles at the top level or some means to get
them from the top level then I have no alternative but to export
createDeviceHandle either directly to the "user level" API (really bad!)
or to some other bit of higher level system code that can be trusted not
to create 2 or more handles for the same device (and no handles for
non-existant devices). Let's assume it's that latter.

In the simple case where it is known at compile time that there are
exactly 2 devices in the system at known base addresses, can you explain
how the higher level bit of the system guarantees that user level
application code will only ever have access to 2 different device
handles in total (one for each device), no matter what?

How does it solve this problem in the more complex complex case where
hardware must be probed somehow to discover how many devices there
are and where they are?

All without using any global variables please. Also, assuming you
succeed, please explain what advantages or extra safety your solution
provides over a solution which does use global variables.

The obvious solution seems to be to have this code present this function
to the user level API..

getAvailableDeviceHandles :: IO [DeviceHandle]

Which shouldn't be hard to implement in either case, except for the fact
IO state "getters" can't be implemented at all without top level mutable
state or runOnce primitives or something like that (AFAICS).

newAvailableDeviceHandles perhaps? I guess that could come in handy
if the user code decides it doesn't like the old ones for some
reason :-)

Regards
--
Adrian Hey