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

Antoine Latter aslatter at gmail.com
Fri Feb 22 09:44:09 EST 2008

I was trying to solve a similar problem while learning the FastCGI
package.  The regular CGI package allows the use of ReaderT to hold
config data.  Because FastCGI does the running of the passed in CGI
action within a few calls to alloca :: (Ptr a -> IO b) -> IO b, I
couldn't figure out a way to use monad transformers.

I settled on the top-level IORef trick I've seen elsewhere:

> bigBallOfState_ :: IORef MyState
> bigBallOfState_ = unsafePerformIO $ newIORef emptyState
> {-# NOINLINE bigBallOfState_ #-}

With a few accessors:

> setState :: MyState -> IO ()
> setState = ...

> getState :: IO MyState
> getState = ...

I'm not going to pretend it's good style, and it assumes you only ever
need one copy of the state everywhere in your program.


On Fri, Feb 22, 2008 at 8:15 AM, Jefferson Heard
<jefferson.r.heard at gmail.com> wrote:
> 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
>  _______________________________________________
>  Haskell-Cafe mailing list
>  Haskell-Cafe at haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-cafe

More information about the Haskell-Cafe mailing list