On Tuesday 18 August 2009, Maurício CA wrote:
...) But for simulation kind-of problems, in which I think OO really fits the best, what's the haskell way to structure such problems? I once thought maybe I can use the State monad to simulate objects. But it's really hard for me to implement, because I think State monad is used to simulate a global shared state, is it right?
Then what's the best way to simulate private states or just instead how to solve simulation problems such as a physical engine using the haskell way?
A physical engine can be simulated using pure code, with a function from timestep to state. (Of course, that doesn't hold when you want to deal with user interaction.) I think there is no general answer to your question. My sugestion is to describe an example you would like to work with.
Hi, I did a medium sized mobility models simulator this way. The simulation is represented as an infinite list of states, where the next state is created by applying a state transformation ("next") function to the previous state. This has the advantage that you can calculate values based on more than one state. The downside is that if you need to look back 100 stesp, you need to remember 100 states (though if enough of it is unchanged and shared then it's not really that much of a problem). As far as the details go -- different parts of the simulator are executed in different monads. "god-mode" code, like the "next" function has the type nextStep :: World -> World but the mobility model implementation (which tells a node how to move) is a stateful computation run by nextStep: mobilityModel :: StateT NodeState (Reader World) () But as Maurício said -- please describe what you want to achieve. At least what kind of simulation you'd like to write. -- Thanks! Marcin Kosiba