ANNOUNCE: Object I/O released

Simon Peyton-Jones
Mon, 8 Apr 2002 04:02:03 -0700


|    The version that I release is based entirely on LS
| version. I think that it is more elegant and more
| useful for customer.=20

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

My defence of the MVar approach is not because I simply=20
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 =3D do
|    st <- takeMVar state
|    ...
|    ...
|    putMVAR state st'
| In LS version there isn't need of takeMVar/putMVAR and
| the handler is more easy.=20
|    2) In MVAR version the event handlers in the device=20
| 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 =3D do { s <- getMVar m; r <- t s'; putMVar m s' }

Now you can write closeWin :: WinState -> IO WinState
if you want. =20

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
one modified by one set of events and one by another, and it would be
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.=20

I don't understand this; you can encapsulate the MVars too, in just
the same way:

windowDevice =3D do { s <- newMVar 0;
			openWindow ... }

No caller of WindowDevice can see the encapsulated MVar.