[Haskell-cafe] State Variables

[minh thu]

ah... simulation in haskell ... that's a thing i thought a bit of ..
(disclaimer : i'm not so good at haskell, so... :)

here how i've started :

you have your global state : it's a bunch of IORef or STRef. Each one
maps to one of the individual thing you want to update. You can choose
the hierarchy (of non-mutable/mutable fields of the global state) you
want. (For example, you can have only one IORef pointing to the whole
state, or having one IORef for each simple variable).

Since all your updatable things are accessed via IORef, you can just
"read" your state with the ReaderT transformer then "writeIORef" to
change the state.

I join two exemple files i've done ... some comments are in french,
others in english.
hope it helps !

mt

2006/5/28, Matthew Bromberg <mattcbro at earthlink.net>:
> I've been toying with the idea of using Haskell to write a medium sized
> simulation
> of a wireless network.  However  I have a number of concerns as I've
> begun to
> program a bit more in Haskell.
>
> The first concern is that the simulation needs to be fast, much faster
> than Matlab
> for example, to justify the use of Haskell.  Given GHCs speed
> improvement in recent
> releases, I have high hopes that this is possible.  To be honest, I'd
> probably pick Clean
> here, but I've been unable to consistently link to third party DLLs with
> the Clean IDE.
>
> The second concern is that the simulation  requires
> heavy use of complex valued matrices.  Since I'm on windows and the
> only reasonably well developed matrix library doesn't run on windows I
> would be forced to use the FFI to bring in various BLAS and LAPACK
> routines to
> support this.  I've convinced myself that this is quite possible, if
> somewhat tedious by
> virtue of the unpleasant array access syntax for mutable arrays.
>
> The third and final concern is the point of this post.  How does one
> handle state efficiently in Haskell?
> I've seen the various state monads and gained a superficial enough
> understanding to be concerned about
> how useful they are, for the following reason:
>
> I would like to aggregrate a large number of state variables (possibly
> in the hundreds of variables) into a few
> data structures.  These structures would not only contain basic variable
> types, but probably some rather large
> mutable arrays.  So lets say I have such a structure called world and I
> wish to update just 1 entry.  If I do
> w=world{entry=newentry}, the entire enormous world structure is copied to w.
>
> If I bury world in a state monad, then inside a do loop it appears that
> the get function extracts the entire world state and
> the set function writes it back into the monad after I've altered it.
> It still seems to me that the entire structure is copied
> again to achieve this.  I'm not sure if this is true or not.  Perhaps
> the compiler can pull apart the aggregation to fix this issue, but I'm
> not sure if such an optimization is performed.  The only other thing I
> could think of would be to somehow create get and set
> functions for every variable in the aggregation, which also would be
> impossibly tedious.
>
> It is possible for me to structure the program so that most of the
> simulation parameters are set once by the user and then
> never changed during the rest of the program operation, although
> incremental state updates are a bit more efficient than this approach.
> To make this reasonably clean I would probably do some kind of unsafe
> extraction out of the IO monad to get my input variables, which
> would then not be changed for the rest of the simulation, although many
> of the matrices, themselves embedded in the IO monad would have to
> change incrementally as the simulation progresses.  Right now I would
> favor the latter approach, if I stay with Haskell, but so far it's not clear
> to me that Haskell is 'convenient' for this kind of development, though
> I would like to be proven wrong.  I am also looking at D or possibly
> LUA+C  for this task, but LUA is not much faster than Matlab.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Programming-01-ReaderT.hs
Type: application/octet-stream
Size: 3048 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060529/73df578c/Programming-01-ReaderT.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Programming-01-ReaderT-IO.hs
Type: application/octet-stream
Size: 1069 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/haskell-cafe/attachments/20060529/73df578c/Programming-01-ReaderT-IO.obj