Is it possible to create a TreeModel for data in a State monad in GTK and Haskell?

Question

I would imagine that the overall answers to this will push me over to Functional Reactive Programming, but... bear with me for a bit.

I also don't have example code for this question. I have wandered near the topic with some of my code, but I have stayed firmly in the IO monad with it.

Imagine that I have an application in which I am modelling somewhat complex state and put it into an overall Application State monad. I am doing it this way because I am wanting a certain level of detachment between my core application and the particular user interface.

data S = S DataStore EventStream Sockets
type AppState m = StateT S m

(assume that DataStore, EventStream, and Sockets are all data types that do basically what they sound like :))

Now, say I want to create a table in GTK (TreeView, but no child nodes) that views only the EventStream. I have already learned to do that by saying listStoreNew event_stream >>= treeViewNewWithModel (see http://markus.alyra.org/?p=1023 where I talked pretty extensively about the mechanics of setting this up).

But, now I have a mutable copy of data that is in my AppState monad. When the application goes off and does something that appends new data to the EventStream, that will not show up in the view. The only way I can think of it make it show up in the view is to send it over with a message like listStoreInsert my_new_event in addition to the changes made to the monad. That's doable, but is starting to feel clumsy.

Worse, though, this mythical tree view is an administrative view! It's editable! The admin says "oh, that event has some invalid data, I want to change it!". Now, I have no problems changing the data that is in the ListStore I created above. I can create callbacks that make the update with no problem. But I cannot think at all of how to get the update into the Global AppState Monad.

And those last few words show the core of the problem. If I have a global AppState Monad, then anything that updates that monad has to be in one line of execution with everything that wants to view the monad. The TreeView breaks that. When a cell gets edited in the TreeView monad, the edit handler runs entirely in the IO monad and is expected to return nothing. The end data type is IO (). Even if I had some nifty way to unwrap data from my AppState, then do the edit handler, and then re-wrap the data in my AppState, no other branch of the application could see it.

Even if I can figure out how to create my own completely custom ModelView instance that provides a read-only view into my AppState, I cannot think of how to make state updates available to the rest of the application.

So...

Is it even possible to model GTK/Haskell application in this way? Or, have I gone down the road to madness?

dflemstr dflemstr · Accepted Answer · 2012-07-11T14:57:19

You have no way of sharing the state reliably using a normal state monad. What if (contrived example) your user edits the model via the GUI and you get a new entry from somewhere else at the same time? You cannot possibly serialize the changes to your state monad in that situation using some pure monad stack.

What you could do is to use some kind of synchronization system using mutable references (With MVars for example); you store the actual application state in an MVar, and whenever something happens that might read or change the state, you access that MVar. Here's some pseudo-code that shows what I mean:

-- This is the MVar that stores your application state
appStateMVar :: MVar S
appStateMVar = unsafePerformIO $ newMVar initialAppState
{-# NOINLINE appStateMVar #-}
-- It could also be passed as a parameter to the functions below, so that when
-- you define the callbacks, you create a closure over the MVar that you use.
-- (i.e.:
-- > appStateMVar <- newMVar initialAppState
-- > createListViewWithCallback $ whenUserAddedSomethingViaTheGUI appStateMVar
-- )
-- That way, you don't have to have the MVar in global scope and can avoid the
-- use of `unsafePerformIO` to initialize it, etc.

main :: IO ()
main = do
  createListViewWithCallback whenUserAddedSomethingViaTheGUI
  createSocketsAndListenUsingCallback whenChangesArriveOverTheNetwork
  runSomeKindOfMainLoop

-- This would be called on any thread by the GUI when the user added something in
-- the view (For example)
whenUserAddedSomethingViaTheGUI :: AddedThing -> IO ()
whenUserAddedSomethingViaTheGUI theThingThatWasAdded =
  takeMVar appStateMVar >>=
  execStateT (addToTheState theThingThatWasAdded) >>=
  putMVar appStateMVar

-- This would be called by the network when something changed there
whenChangesArriveOverTheNetwork :: ArrivedChanges -> IO ()
whenChangesArriveOverTheNetwork theChangesThatArrived =
  takeMVar appStateMVar >>=
  execStateT (handleChanges theChangesThatArrived) >>=
  putMVar appStateMVar

Then, you can write addToTheState and handleChanges using a pure AppState monad, just like you did before.

Of course, if you decide to use FRP, you can avoid this very imperative-style state wiring by letting your application state be a pure signal that changes over time. I understand that reactive-banana has done some work that makes it possible to integrate bi-directional GUI editors/views with FRP event networks.

Is it possible to create a TreeModel for data in a State monad in GTK and Haskell?

1 Answers