title: Maintaining complex state in Haskell
body: <p>Suppose you're building a fairly large simulation in Haskell. There are many different types of entities whose attributes update as the simulation progresses. Let's say, for the sake of example, that your entities are called Monkeys, Elephants, Bears, etc..</p>
  
  <p>What is your preferred method for maintaining these entities' states?</p>
  
  <p>The first and most obvious approach I thought of was this:</p>
  
  <pre><code>mainLoop :: [Monkey] -&gt; [Elephant] -&gt; [Bear] -&gt; String
  mainLoop monkeys elephants bears =
    let monkeys'   = updateMonkeys   monkeys
        elephants' = updateElephants elephants
        bears'     = updateBears     bears
    in
      if shouldExit monkeys elephants bears then "Done" else
        mainLoop monkeys' elephants' bears'
  </code></pre>
  
  <p>It's already ugly having each type of entity explicitly mentioned in the <code>mainLoop</code> function signature. You can imagine how it would get absolutely awful if you had, say, 20 types of entities. (20 is not unreasonable for complex simulations.) So I think this is an unacceptable approach. But its saving grace is that functions like <code>updateMonkeys</code> are very explicit in what they do: They take a list of Monkeys and return a new one.</p>
  
  <p>So then the next thought would be to roll everything into one big data structure that holds all state, thus cleaning up the signature of <code>mainLoop</code>:</p>
  
  <pre><code>mainLoop :: GameState -&gt; String
  mainLoop gs0 =
    let gs1 = updateMonkeys   gs0
        gs2 = updateElephants gs1
        gs3 = updateBears     gs2
    in
      if shouldExit gs0 then "Done" else
        mainLoop gs3
  </code></pre>
  
  <p>Some would suggest that we wrap <code>GameState</code> up in a State Monad and call <code>updateMonkeys</code> etc. in a <code>do</code>. That's fine. Some would rather suggest we clean it up with function composition. Also fine, I think. (BTW, I'm a novice with Haskell, so maybe I'm wrong about some of this.)</p>
  
  <p>But then the problem is, functions like <code>updateMonkeys</code> don't give you useful information from their type signature. You can't really be sure what they do. Sure, <code>updateMonkeys</code> is a descriptive name, but that's little consolation. When I pass in a <a href="http://en.wikipedia.org/wiki/God_object" rel="noreferrer">god object</a> and say "please update my global state," I feel like we're back in the imperative world. It feels like global variables by another name: You have a function that does <em>something</em> to the global state, you call it, and you hope for the best. (I suppose you still avoid some concurrency problems that would be present with global variables in an imperative program. But meh, concurrency isn't nearly the only thing wrong with global variables.)</p>
  
  <p>A further problem is this: Suppose the objects need to interact. For example, we have a function like this:</p>
  
  <pre><code>stomp :: Elephant -&gt; Monkey -&gt; (Elephant, Monkey)
  stomp elephant monkey =
    (elongateEvilGrin elephant, decrementHealth monkey)
  </code></pre>
  
  <p>Say this gets called in <code>updateElephants</code>, because that's where we check to see if any of the elephants are in stomping range of any monkeys. How do you elegantly propagate the changes to both the monkeys and elephants in this scenario? In our second example, <code>updateElephants</code> takes and returns a god object, so it could effect both changes. But this just muddies the waters further and reinforces my point: With the god object, you're effectively just mutating global variables. And if you're not using the god object, I'm not sure how you'd propagate those types of changes.</p>
  
  <p>What to do? Surely many programs need to manage complex state, so I'm guessing there are some well-known approaches to this problem.</p>
  
  <p>Just for the sake of comparison, here's how I might solve the problem in the OOP world. There would be <code>Monkey</code>, <code>Elephant</code>, etc. objects. I'd probably have class methods to do lookups in the set of all live animals. Maybe you could lookup by location, by ID, whatever. Thanks to the data structures underlying the lookup functions, they'd stay allocated on the heap. (I'm assuming GC or reference counting.) Their member variables would get mutated all the time. Any method of any class would be able to mutate any live animal of any other class. E.g. an <code>Elephant</code> could have a <code>stomp</code> method that would decrement the health of a passed-in <code>Monkey</code> object, and there would be no need to pass that</p>
  
  <p>Likewise, in an Erlang or other actor-oriented design, you could solve these problems fairly elegantly: Each actor maintains its own loop and thus its own state, so you never need a god object. And message passing allows one object's activities to trigger changes in other objects without passing a bunch of stuff all the way back up the call stack. Yet I have heard it said that actors in Haskell are frowned upon.</p>