[Haskell-cafe] Mitigating state-threading through an application loop

[Michael Serra]

Hello Haskellers,
  I'm implementing a simple tree-manipulating (for sports tournaments)
application prototype, with SDL for graphics and simple user interaction.
For reference, I've posted the code on hpaste. <http://hpaste.org/55506>
My question is about code organization: everything was simple and elegant
until I started writing the program's display/event loop.  Every function
in this section has to be passed the same parameters - the application
window to draw on, the font to display text with, the tree representing the
current application state, etc.  The font is an especially egregious
example of the problem, because it's only used by one function but to get
there it must be threaded through all of them (looking at the hpaste, you
will see I don't want to call openFont on every invocation of drawTexts;
what's needed is to call it once in main and have the resulting value
available to drawTxt.  So my question: how can I mitigate the ugliness of
this state-threading?  I understand this is one purpose for monads; am I
supposed to implement a monad transformer for this?

I think it would be great if I could define a type AppState as a tuple of
the various things I need to thread, and specify some kind of automatic
as-pattern, so that every function taking this AppState parameter would
implicitly have its components bound to certain preset names.  I've never
seen anyone do this however.  What is the right solution?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111220/c1e2a772/attachment.htm>