Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, mo

Well, obviously, a game state can change even if a player had no input. So you would have to have some concept of an empty player input on your model. (Also, modern games often require pulling from databases, remote servers... It's not just about transforming game states and rendering them any more.) The problem with games are that they have a lot of state, and a lot of loopy state. You end up in a place where you have a set of entities which are organized into a graph and you need to traverse this graph and destructively update some elements in a way that is visible immediately to all elements. You can do this in Haskell, but... It won't be easy. Definitely much tougher than doing it in C, and at the end of the day your game written in idiomatic Haskell will be more complicated and less performant than the C solution. Also, see: http://prog21.dadgum.com/3.html http://prog21.dadgum.com/3.html http://prog21.dadgum.com/23.html http://prog21.dadgum.com/23.html