[Haskell-cafe] Tutorial for using the state monad or a better suggestion?

Jefferson Heard jefferson.r.heard at gmail.com
Fri Feb 22 09:15:43 EST 2008


So the reason I keep pinging the list so much of late is I'm currently
writing a GLUT program to visualize a heirarchical clustering of
18,000+ protein-protein interaction pairs (and associated
gene-ontology terms).  Thanks for the help on reading CSVs, those who
wrote me back...  my program intitializes and displays its first image
within 6 seconds, about 10 times faster and in 10 times less memory
than the Java program the guy was using.

Now I'm to the point of making this thing interactive, and I I'm
trying to figure out the Haskell way of doing this.  Last time I wrote
a program like this, I made a record data type with all the state and
placed it into an IORef and curried it into the GLUT callback
functions.  I'm going to do the same thing now if there aren't cringes
and wailings from people with a better sense of pure-functional
aesthetics out there on the list with a willingness to either point me
towards a tutorial that would help me do this better.  Keep in mind
that Graphics.UI.GLUT callbacks all want to return an IO (), and thus
leftover state monads at ends of functions aren't going to be
acceptable to the standard library...

Any ideas?  Oh, currently my program state includes:

The geometry I'm rendering (Ptr GLfloat vertex and color arrays),
The same geometry as a display list for rendering into the selection buffer
An indexed and named tree that represents the clustering
A tree of text containing tooltips to display
The previous current mouse position (for dragging purposes)
A couple of histograms as Array.IArray.Diff.DiffArrays
Various parameters for constructing rendered data out of the indexed
tree (for reconstruction after a node is collapsed/expanded)

So I'm carrying around some pretty bulky state; should give you some
understanding as to why I thougt the record data type would be the
sanest way to do this without polluting my parameter list with
individual IORrefs.

Oh, and again, it's not that I don't know that I can make the IORef
solution work, I can and I've done it before.  It's just that I
thought there might be a prettier way to do this.

Thanks in advance!

-- Jeff


More information about the Haskell-Cafe mailing list