Hello Krasimir, I am very curious about your implementation of the Object I/O system, but unfortunately could not open the .zip files either (same symptoms as Arjan van IJzendoorn wrote). Could you check the formats of these files? Thanks in advance. Simon Peyton-Jones wrote:

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).

This issue was one of the key design issues Simon and I had to resolve when porting the Clean Object I/O system to Haskell. The arguments in the above mentioned paper are still valid. Briefly, one can summarise them as: MVar-s offer many significant advantages (simpler types, simpler implementation, more expressive power, programming style similar to handling of identifier values) but have one disadvantage (state management is done by the programmer). As it happens, I am about to spend a couple of weeks (re)designing/implementing/bug-fixing the Object I/O library, and this issue is high on my priority list. I think this is a delicate design decision that should be taken with care, as it has impact on all existing programs and all implementations :-). Regards, Peter Additional remarks to those of Simon:

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.

But the reverse case is also true: in the LS version, an event handler must modify local state. So a function that is really not interested in the local state is either polymorphic in the local state or uses the local state lifting function (noLS and noLS1). In the MVAR version one wouldn't be bothered with this.

| | 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.

The main point of 'LS advocates' is that encapsulation is guaranteed by construction, while it is a program property in the MVAR system. This is of course a GOOD thing. However, this characteristic of LS is also its weakness: one simply can't (partially) share local state between GUI components of different top-level parents (except of course on the highest level within the interactive process) even though in practice this would make a lot of sense. One also can't easily modify event handlers once a GUI structure has been created, even if one would `know' the proper local state type because of the strong encapsulation (you can do it, but this requires quite some overhead, using typed message passing). In short, we have the following: MVAR subsumes LS (we can write more programs), but the price to pay is at least: less static error checking and more proof obligations wrt. locality of state. Perhaps there is an interesting alternative that covers all GOOD points and has fewer BAD points.