Lennart Augustsson wrote:
I was going to respond, but Cale very eloquently said most of what I was thinking.
I don't think eloquent is the word I would use, but I'm certainly glad you didn't feel the need to repeat all that. It'd be really nice if just for once the "global mutable state is evil" folk could give unsafePerformIO hack users the benefit of the doubt, not start out from the presumption that we are a bunch of lazy incompetent retards who are badly in need of education in the rudiments of the IO monad and (allegedly) good programming practice in general. These arguments about the language needing to protect users from doing dangerous things (specifically creating top level mutable state) are quite wrong headed. Concurrency can be dangerous too, so should we lose it? Top level mutable state can be a way of *gaining safety*, not losing it. What really frustrates me about all this is that AFAIK there are no significant technical or theoretical reasons why we can't get this safety (without resort to the unsafePerformIO hack). The only serious obstacle seems political, with this very strange but apparently widespread dogma about so called "global variables" being inherently evil, regardless of the circumstances or purpose for which they are used. With regard to Roberts post, I don't want too say much other than Robert is the first person to provide an answer to my question. I hope I'm not mis-representing his views, but I believe Robert objects to the existence of IO libraries that could not be implemented in Haskell (in principle). I.E. those that implicitly reference top level mutable state. I might be missing something, but AFAICS just about all the current IO libraries fall into this category. To take a specific example, look at the socket API. None of the functions there take any kind of OS or network sub-system state handle as an explicit argument. So it seems to me that either the implementation is entirely stateless, all the way down to peeking and poking the registers of Ethernet MACs, DMA controllers and wotnot (unlikely), or it's sneakily accessing top level mutable state in some extremely devious and non-transparent manner (heaven forbid). Or put another way, would it be possible to implement the socket API, exactly as it currently is, entirely in Haskell, starting with nothing but hardware? I don't believe it is possible, but perhaps somebody can show me I'm wrong.
Let me just add one thing. Sometimes you hear the argument "I need a global IORef here because it's to track the use of my single screen" (or keyboard, or elevator, or some some other gizmo in th real world).
No, this is not the justification for the creation of top level TWI's. This is the justification for not requiring that the API that mutates a particular top level TWI state takes that state as an explicit argument. There's no point if there is (and can be) only one of them. This is why you don't have to pass an OS state handle to every IO function that interacts with "the" OS (note singular). But even if there are two or more, you still need some mechanism to ensure that you have precisely 1:1 correspondance between physical devices and device state TWI's and/or device driver threads. This more or less prevents a robust API allowing unconstrained creation of new device state TWI's. It's far safer and simpler to provide top level TWIs (state handles) as *abstract data types* (not IORefs!). This is no different from (or less safe than) having stdout appear at the top level. Even if there is an unknown (at compile time) number of such devices and instead they are discovered somehow at boot time, you still need to maintain a some kind of finite pool of these device states, which is itself necessarily a unique TWI. IME, the approach you take to these kinds of problems can vary depending what you know or don't know for certain about the system your working with. But you always end up using top level mutable state somewhere along the way. I can only assume folk who insist it's unnecessary (or worse) have never actually tried implementing an IO sub-system from the ground up, starting with nothing but bare hardware.
I think such decisions are just generally poor design, and it should not be done in any language. The number of physical resources that a program can control should never be assumed to be one; things change.
So is it reasonable to assume that there is only one OS? Perhaps it would be best to let individual Haskell users decide for themselves what assumptions are or are not reasonable in the context of their work. Regards -- Adrian Hey