On 17 February 2011 19:48, Stephen Sinclair <radars...@gmail.com> wrote: [SNIP] > However, there is this common pattern in media- or simulation-oriented > programs (like games too): > > 1. Initialize state. > 2. Update state based on initial state. > 3. Update state based on state 2. > 4. Update state based on state 3. > ... > > or more succinctly.. > > t=0. Initialize state. > t=t+1. Update state based on state t-1. > > It seems to me that if it can be proven that state t depends only on > state t-n, then memory for states before t-n can be reused. If n is > known at compile time, which can be true for a lot of signal > processing applications, this should be feasible. If states t-n to t > are treated as immutable, then it could be considered as pure from an > outside perspective, something like the ST monad for instance.
[Maybe off going topic, maybe not...] Martin Erwig and Paul Hudak did quite a bit of work around the topic "functional update" that seems not to have got the attention it might deserve. I've been curious for a while whether this work isn't still pertinent: Paul Hudak "Mutable Abstract Datatypes - or - How to Have Your State and Munge It Too" Yale Research Report RR-914 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.3875 Martin Erwig "The Categorical Imperative - Or: How to Hide Your State Monads" http://web.engr.oregonstate.edu/~erwig/papers/CategoricalImperative_IFL98.pdf The latter is actually in the ST monad but it still seems quite different from today's state-of-the-art of ByteString, Builders and Stream-Fusion. _______________________________________________ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
