Program design in Haskell: how to do simulation without mutability

Question

I have a question about the best way to design a program I'm working on in Haskell. I'm writing a physics simulator, which is something I've done a bunch in standard imperative languages, and usually the main method looks something like:

while True:
  simulationState = stepForward(simulationState)
  render(simulationState)

And I'm wondering how to do something similar in Haskell. I have a function step :: SimState -> SimState and a function display :: SimState -> IO () that uses HOpenGL to draw a simulation state, but I'm at a loss as to how to do this in a "loop" of sorts, as all of the solutions I can come up with involve some sort of mutability. I'm a bit of a noob when it comes to Haskell, so it's entirely possible that I'm missing a very obvious design decision. Also, if there's a better way to architect my program as a whole, I'd be glad to hear it.

Thanks in advance!

Answer 1

In my opinion, the right way to think about this problem is not as a loop, but as a list or other such infinite streaming structure. I gave a similar answer to a similar question; the basic idea is, as C. A. McCann wrote, to use iterate stepForward initialState, where iterate :: (a -> a) -> a -> [a] “returns an infinite list of repeated applications of [stepForward] to [initialState]”.

The problem with this approach is that you have trouble dealing with a monadic step, and in particular a monadic rendering function. One approach would just be to take the desired chunk of the list in advance (possibly with a function like takeWhile, possibly with manual recursion) and then mapM_ render on that. A better approach would be to use a different, intrinsically monadic, streaming structure. The four that I can think of are:

• The iteratee package, which was originally designed for streaming IO. I think here, your steps would be a source (enumerator) and your rendering would be a sink (iteratee); you could then use a pipe (an enumeratee) to apply functions and/or do filtering in the middle.
• The enumerator package, based on the same ideas; one might be cleaner than the other.
• The newer pipes package, which bills itself as “iteratees done right”—it's newer, but the semantics are, at least to me, significantly clearer, as are the names (Producer, Consumer, and Pipe).
• The List package, in particular its ListT monad transformer. This monad transformer is designed to allow you to create lists of monadic values with more useful structure than [m a]; for instance, working with infinite monadic lists becomes more manageable. The package also generalizes many functions on lists into a new type class. It provides an iterateM function twice; the first time in incredible generality, and the second time specialized to ListT. You can then use functions such as takeWhileM to do your filtering.

The big advantage to reifying your program’s iteration in some data structure, rather than simply using recursion, is that your program can then do useful things with control flow. Nothing too grandiose, of course, but for instance, it separates the “how to terminate” decision from the “how to generate” process. Now, the user (even if it's just you) can separately decide when to stop: after n steps? After the state satisfies a certain predicate? There's no reason to bog down your generating code with these decisions, as it's logically a separate concern.

Answer 2

Well, if drawing successive states is all you want to do, that's pretty simple. First, take your step function and the initial state and use the iterate function. iterate step initialState is then an (infinite) list of each simulation state. You can then map display over that to get IO actions to draw each state, so together you'd have something like this:

allStates :: [SimState]
allStates = iterate step initialState

displayedStates :: [IO ()]
displayedStates = fmap display allStates

The simplest way to run it would be to then use the intersperse function to put a "delay" action between each display action, then use the sequence_ function to run the whole thing:

main :: IO ()
main = sequence_ $ intersperse (delay 20) displayedStates

Of course that means you have to forcibly terminate the application and precludes any sort of interactivity, so it's not really a good way to do it in general.

A more sensible approach would be to interleave things like "seeing if the application should exit" at each step. You can do that with explicit recursion:

runLoop :: SimState -> IO ()
runLoop st = do display st
                isDone <- checkInput
                if isDone then return () 
                          else delay 20 >> runLoop (step st)

My preferred approach is to write non-recursive steps instead and then use a more abstract loop combinator. Unfortunately there's not really good support for doing it that way in the standard libraries, but it would look something like this:

runStep :: SimState -> IO SimState
runStep st = do display st
                delay 20
                return (step st)

runLoop :: SimState -> IO ()
runLoop initialState = iterUntilM_ checkInput runStep initialState

Implementing the iterUntilM_ function is left as an exercise for the reader, heh.

Answer 3

Your approach is ok, you just need to remember that loops are expressed as recursion in Haskell:

simulation state = do
    let newState = stepForward state
    render newState
    simulation newState

(But you definietly need a criterion how to end the loop.)