Tuesday, December 15, 2009, 5:23:41 PM, you wrote:
ST monad is the same as IO monad modulo type trickery. tris trickery
allows to limit imperative operations available inside ST monad to
STRef/STArray manipulations which is guaranteed to be
referential-transparent as part of this trickery. STRef/STArray is,
again, equivalent to IORef/IOArray modulo this trickery
so basically we say "there is safe subset of IO operations, let's give
them acces in the way that prevents their unsafe use", makes
ST/STRef/STArray/runST newtypes wrapped around
IO/IORef/IOArray/unsafePerformIO and export
them to user w/o providing access to implementation details
ST monad doesn't contain any hidden state - at least when we say from
*implementation* point of view
> AFAIK, ST Arrays are pure data structures. They are not really
> mutable. They are destroyed and recreated on every update. The
> mutation is just simulated thanks to the hidden state in the state
> monad. Sure, the garbage collector must have a hard work in
> recycling all the "backbones" of the discarded arrays (not the elements).
> 2009/12/14 Brad Larsen <[email protected]>
> Is anyone working on fixing ticket #650
> <http://hackage.haskell.org/trac/ghc/ticket/650>? In short, STArray
> and the garbage collector don't play well together, resulting in array
> updates being non-constant time operations. This bug makes it very
> difficult/impossible to write efficient array algorithms that depend
> upon mutation in Haskell.
> On another note, does this (or perhaps better phrased, will this) bug
> also affect Data Parallel Haskell?
> I would really like to see highly efficient, mutable, boxed arrays in
> Haskell! Unfortunately, I don't have the know-how to fix Ticket 650.
> Haskell-Cafe mailing list
> [email protected]
Bulat mailto:[email protected]
Haskell-Cafe mailing list