
Hello Alberto, 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
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.
Sincerely, Brad
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com