Lennart Augustsson wrote:
Adrian Hey wrote:
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. If I get to implement the IO monad, sure. :)
Perhaps you could give some indication of what you have in mind? AFAICS the problem, if it is a problem, is a semantic problem that afflicts all IO monad implementations. What would be different about your implementation?
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've written about 50000 lines of USB devices drivers for *BSD (in C). They work from the bare metal and up. They contain no global mutable state (except for variables that define debugging levels, because you need to access these from the in-kernel debugger).
Yes, I was aware of this. But with all due respect, if you're running with an OS already present (not what I would call bare metal :-), your device driver alone is not the entire IO sub-system. I'm not sure what you mean by it having no mutable state. Do you mean no top level mutable state, or do you mean there is no mutable state whatsoever associated with a particular USB port(device..whatever)? I assume you mean the former, and that the mutable device state itself is passed as a parameter to your code, some how. If so I think this is fine and good practice (even my noddy device driver on the wiki does this). But it seems to me when you consider the system as whole, the real problem is the creation, management and aquisition of the device states (state handles) by software that uses particular devices. I'll try to keep this brief, maybe you or someone else can explain the flaw in my logic, if there is one.. Consider a bit of code in the IO monad that needs a device handle to perform some IO action with the corresponding device. How does it acquire this handle? I can think of 3 ways.. 1- It receives it as an argument. No problem, except when I look at the Haskell libraries most of them don't seem to be taking such arguments (main takes none whatsoever). 2- It creates it locally with some kind of newDeviceState constructor. Well there might be some particularly privileged bit of code somewhere in the system that is allowed to do this, but clearly this isn't an option for most code. 3- It gets from some other data structure which is accessible at the top level. IOW a "global variable". This doesn't seem to be an option either in a language that has been designed to prevent the creation of such things. Unless I'm missing something, there seems to be a very serious problem somewhere. If so, it should be fixed IMO, one way or another. Now as JM mentioned, the reason nobody seems to notice this problem is that in reality folk *are* relying on "global variables" somewhere in the system. But they're buried so deeply in unsafePerformIO hacked Haskell libraries, C libraries and OS internals that nobody notices. They're just accepted as being part of "the world". So when people say things like "I have never ever had to use a global variable", I'm inclined to believe them. But I also say that the only reason they can claim to be without "sin" is because somebody else has already sinned on their behalf to provide them with the IO libraries they use. Regards -- Adrian Hey