ANNOUNCE: Object I/O released

[Peter Achten]

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.