Achim Schneider wrote:
Yes, you see, that was my first Haskell program bigger than 20 lines, there's no possibility to get the state out of the IO Monad, at least without writing a high-level interface to glut and gl, and then there's this thing that _every_ game works with input callbacks, one, global, state update function (where it doesn't _really_ matter whether you're passing and returning a state or updating a state) and one function that translates the state into some graphics representation.
Understood. My objection was not about having an IORef somewhere (you need it to thread via the callback), but about making each component an IORef when one big IORef makes more sense. It makes plenty of sense to try to write precise type signatures, including not having IO in the type of functions which don't do IO. For ramblings about the annoyance of having to use IORefs to thread your custom monad state through callbacks, take a look at http://www.haskell.org/pipermail/haskell-cafe/2007-July/028501.html which sketches a typeclass "solution" Jules