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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
