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