Victor Nazarov wrote:
Hello,
I've been writing some GUI application with Gtk2hs. It's an
interpreter for lambda-calculus and combinatory logic, it's GPL and if
you interested I can share it with cafe.
The problem is that the GUI code has become very ugly and I'm tempted
to rewrite it totally. I've been looking forward to the FRP stuff, but
I've never seen a single definition of the term. Conal Eliot's
"denotational programming" is too general to be definition. I want to
try Grapefruit, but I got totally lost when I see arrow notation.
I consider more lightweight and more imperative approach, something
closer to CSP (Communicating Secuential Processes) then FRP. I've just
crafted some sample program to illustrate my idea.
The behaviour is a monad and it's IO monad so you can do any IO
(Gtk2hs) programming you wish. The differences is that you don't
attach static event handlers and tries to determine what to do
dependent on application state. You attach and detach handlers as much
as possible. Behaviour looks like a process that can stop execution
and wait for some GUI event. When event arrived it continues
execution.
To summarize, the behaviour is a suspendable IO computation. It looks
very much like a coroutine, in fact. I'm planning to extract the
Control.Concurrent.Coroutine module [1] into a separate package soon. It
implements a similar concept but generalized to transform any monad and
any functorial suspension.
[1]
http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concurrent-Coroutine.html
Do you see this approach viable. There are steel some details to emerge:
* How to wait for several events
* How to handle IO exceptions
I don't really know how applicable the idea is to GUI programming.
That's not my area of expertise. I am surprised, though, that neither
your code not your comments seem to address the issue of concurrency, as
I expect that would be crucial in a GUI setting. Wouldn't you need
different behaviours to run in different threads?
Here is the code:
{-# LANGUAGE ExistentialQuantification #-}
...
I don't see the purpose of your BBind constructor. It seems to me that
you could simply move the first three cases of runBehaviour
implementation into your >>= and get rid of the constructor. Do you
need that much laziness?
import Data.IORef
import System.Glib
import Graphics.UI.Gtk
import Control.Monad.Trans
type Event obj = IO () -> IO (ConnectId obj)
data Behaviour a =
forall b. BBind (Behaviour b) (b -> Behaviour a)
| BIO (IO a)
| forall obj. GObjectClass obj => BWaitEvent (Event obj) (Behaviour a)
instance Monad Behaviour
where action >>= generator = BBind action generator
return a = BIO (return a)
instance MonadIO Behaviour
where liftIO action = BIO action
runBehaviour :: Behaviour a -> IO a
runBehaviour (BBind (BWaitEvent event after) f) = runBehaviour
(BWaitEvent event (after >>= f))
runBehaviour (BBind (BIO a) f) = a >>= \x -> runBehaviour (f x)
runBehaviour (BBind (BBind a f) g) = runBehaviour (a >>= (\x -> f x >>= g))
runBehaviour (BIO a) = a
runBehaviour (BWaitEvent event after) =
do sigIdRef <- newIORef (error "You can't access sigIdRef before
signal is connected")
sigId <- event $
do sigId <- readIORef sigIdRef
signalDisconnect sigId
runBehaviour after
return ()
writeIORef sigIdRef sigId
return (error "You can't expect result from behaviour")
waitEvent :: GObjectClass obj => Event obj -> Behaviour ()
waitEvent event = BWaitEvent event (return ())
main :: IO ()
main =
do initGUI
window <- windowNew
onDestroy window mainQuit
set window [windowTitle := "Hello World"]
button <- buttonNew
let buttonB label =
do liftIO $ set button [buttonLabel := label]
waitEvent (onClicked button)
buttonB (label ++ "*")
runBehaviour (buttonB "*")
set window [containerChild := button]
widgetShowAll window
mainGUI
------------------------------------------------------------------------
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Mario Blazevic
mblaze...@stilo.com
Stilo International
This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
