Krasimir | The version that I release is based entirely on LS | version. I think that it is more elegant and more | useful for customer. I'm delighted and impressed that you have completed the Object I/O port, but I don't think I agree with you about the MVar/LS issue. A note to other readers: the issue is whether it is better, from the programmer's point of view, to use MVars to manipulate state, or to use the state parameterisation that Clean uses. This issue is discussed in the paper by Peter Achten and mself http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm My defence of the MVar approach is not because I simply think that MVars are best for everything! It's because I have really struggled to understand the types in the Clean I/O system, and they become *so* much simpler when the state parameterisation is left out. And if I struggle, then I fear that novice programmers may be in real difficulty. I think that even Peter Achten thought this too, having done it both ways (but I should let him speak for himself). To respond to your points: | 1) In the MVAR version each event handler must like | this: | | eventHandler state = do | st <- takeMVar state | ... | ... | putMVAR state st' | | In LS version there isn't need of takeMVar/putMVAR and | the handler is more easy. | | 2) In MVAR version the event handlers in the device | definitions must be defined as curry functions | | Example MVAR: | state <- newMVAR (0::Int) | openWindow (Window NilLS [WindowClose (closeWin | state)]) | | Example LS: | openWindow (0::Int) (Window NilLS [WindowClose | closeWin]) Both are true, but you can easily wrap up the state passing if that is what you want: state <- newMVAR (0::Int) openWindow (Window NilLS [WindowClose (handle state closeWin)]) handle :: MVar a -> (a -> IO a) -> IO () handle m t = do { s <- getMVar m; r <- t s'; putMVar m s' } Now you can write closeWin :: WinState -> IO WinState if you want. Of course the reference to the state is still explicit, but I do not think that is a bad thing. It tells you where that MVar can be modified (and where it can't!). There might be two pieces of state for one component, one modified by one set of events and one by another, and it would be nice to make that apparent. | 3) Modification of local state doesn't mean | modification of device behaviour. The behaviour of the | device is described with both local state and internal | device data. This means that direct access to the | state isn't a good idea. In the LS version the local | state is encapsulated in the device and I think that | this is more OOP style. I don't understand this; you can encapsulate the MVars too, in just the same way: windowDevice = do { s <- newMVar 0; openWindow ... } No caller of WindowDevice can see the encapsulated MVar. Simon