ANNOUNCE: Object I/O released
PThe first release, 0.1, of Object I/O is now available. PThe Object I/O for Haskell library is a port of standard Clean Object I/O library. The general structure of the Haskell version is inherited from the original library but there are also few differences provoked from the languages differences. PObject I/O allows Haskell programmers to build rich graphical user interface. This release support only Windows platform. Features include: P* Modal and nonmodal dialogs P* Nonmodal resizeable windows P* Toolbars and menus P* Various kind of controls and possibility to build custom controls P* Layout manager for controls P* Timers. The timer simplifies building of little games. See examples. P* Support for file opening with drag drop PQuick reference is available from: A href=http://free.top.bg/ka2_mail/objectio-ref.zip; http://free.top.bg/ka2_mail/objectio-ref.zip/A PBinary package compiled with GHC-5.02.1 A href=http://free.top.bg/ka2_mail/objectio.zip; http://free.top.bg/ka2_mail/objectio.zip/A PExamples A href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples/A PSource package A href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/A __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: Object I/O released
--- Simon Peyton-Jones [EMAIL PROTECTED] wrote: Well done! You never responded to my question about MVars... Simon The version that I release is based entirely on LS version. I think that it is more elegant and more useful for customer. 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]) 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. Communication between devices is posible only with message dispatching, that is better object oriented tehnology. __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: Object I/O released
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
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: Object I/O released
--- Peter Achten [EMAIL PROTECTED] wrote:
Perhaps there is an interesting alternative that
covers all GOOD points and has fewer BAD points.
Some pieces of library can be simplified if redefine:
data WindowLSHandle ls ps
= WindowLSHandle
{ wlsState:: ls
, wlsHandle :: WindowHandle ls ps
}
as
data WindowLSHandle ls ps
= WindowLSHandle
{ wlsState:: MVar ls-- or IORef ls
, wlsHandle :: WindowHandle ls ps
}
That let Object I/O to manage local state but
simplifies implementation of WindowDevice (see
WindowDevice.hs). There isn't need of fixIO and not
need to use of build function. This also simplifies
creation of modal dialogs and synchronous message
passing. The current implementation uses
unsafeTypeCast function which is not a good idea.
In this implementation the type system is still
complicated but my decision is just to skip type
declarations and let compiler to resolve function
types for me. In my experience with Object I/O I
notice that type error is usually logical error. So
types for me isn't a trouble.
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
