Implementing tree/list data models in Haskell

Another idea for improving the tree/list stuff would be to allow the data model to be defined in Haskell. That way one would not have to make do with the two models provided by Gtk+, the TreeStore and the ListStore. These are rather cumbersome to use from Haskell since it all has to be done in the IO monad. Also it doesn’t feel ideal since you’re having to stuff your data into a different structure rather than just providing an adaptor for your existing data model.

Now the Gtk+ tree/list system is designed to follow the model/view/controller pattern so it does allow you to create your own models that implement the GtkTreeModel interface. However Gtk2Hs does not provide a way to implement the GtkTreeModel interface using Haskell. So my suggestion is to do just that.

I’m not quite sure how this would pan out but I think it’s worth a go. It can’t be worse than the existing system! :-)

This would be implemented by writing in C a HaskellTreeStore that implementes the GtkTreeModel interface and deligates its implementation to a Haskell implementation. The Haskell implementation would probably be an instance of some new type class, lets call it TreeModelInterface.

So suppose you have some data and you want to connect it up to a list widget.

data MyDataset = ...

Then you would need to make it an instance of the TreeModelInterface

instance TreeModelInterface MyDataset where
  getNumberOfRows mydataset = ...
  getValue mydataset row = ...
  ...

Then if you’ve got a value of your MyDataset type then you could construct a TreeModel:

treeModelNew :: TreeModelInterface model => -> TreeModel

So you would then connect this new model to a view in much the same way as one currently does with the TreeStore and the ListStore models.

These names are not the greatest, just the first thing I thought of, suggestions welcome.

2 Responses to “Implementing tree/list data models in Haskell”

  1. Axel Says:

    I wonder if storing the data in Haskell land will provide that much benefit. At the end of the day, each update will have to call an IO operation to make the changes permanent which is no better than to change the Gtk models that live in C land. The real benefit of creating a Haskell model is if the data is actually not stored in the current program at all, i.e. if the data is stored in a database. In this case the model would perform an SQL query each time the view requests new rows, thereby reducing the amount of data that the program holds. It would be nice to provide a Haskell interface to allow the implementation of such a model since it is quite involved (updates in the view and the data base have to be reflected in the database and the view, respectively).

  2. Duncan Says:

    Yes, the model always has to notify the view of changes. However it might be possible to reduce the pain of that, especially for bulk operations.

    The design of the Haskell side of the TreeModel interface would need some thought to minimise the intrusion of IO into everything.

    For example it would work just fine for static models. The GHC profile viewer for example is basically a static model with an adjustable filter. That could probably be implemented in a simpler way by using a custom model.