<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Alberto G. Corona</b> <span dir="ltr"><<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>></span><br>
Date: 2009/12/15<br>Subject: Re: [Haskell-cafe] Boxed Mutable Arrays<br>To: Daniel Peebles <<a href="mailto:pumpkingod@gmail.com">pumpkingod@gmail.com</a>><br><br><br>Ok, so the state content is not accessible. Nice.<br>
<br><div class="gmail_quote">2009/12/15 Daniel Peebles <span dir="ltr"><<a href="mailto:pumpkingod@gmail.com" target="_blank">pumpkingod@gmail.com</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, they are actually being mutated. ST is basically IO with a<br>
universal state thread (IO uses RealWorld) to prevent you from letting<br>
any of the mutable structures out (or any in) of the block. The whole<br>
point of ST is to have real mutable references/arrays that have a<br>
referentially transparent if you look at them from outside.<br>
<br>
Dan<br>
<div><div></div><div><br>
On Tue, Dec 15, 2009 at 9:23 AM, Alberto G. Corona <<a href="mailto:agocorona@gmail.com" target="_blank">agocorona@gmail.com</a>> wrote:<br>
> AFAIK, ST Arrays are pure data structures. They are not really mutable. They<br>
> are destroyed and recreated on every update. The mutation is just simulated<br>
> thanks to the hidden state in the state monad. Sure, the garbage collector<br>
> must have a hard work in recycling all the "backbones" of the discarded<br>
> arrays (not the elements).<br>
><br>
> 2009/12/14 Brad Larsen <<a href="mailto:brad.larsen@gmail.com" target="_blank">brad.larsen@gmail.com</a>><br>
>><br>
>> Is anyone working on fixing ticket #650<br>
>> <<a href="http://hackage.haskell.org/trac/ghc/ticket/650" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/650</a>>? In short, STArray<br>
>> and the garbage collector don't play well together, resulting in array<br>
>> updates being non-constant time operations. This bug makes it very<br>
>> difficult/impossible to write efficient array algorithms that depend<br>
>> upon mutation in Haskell.<br>
>><br>
>> On another note, does this (or perhaps better phrased, will this) bug<br>
>> also affect Data Parallel Haskell?<br>
>><br>
>> I would really like to see highly efficient, mutable, boxed arrays in<br>
>> Haskell! Unfortunately, I don't have the know-how to fix Ticket 650.<br>
>><br>
>> Sincerely,<br>
>> Brad<br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
><br>
</div></div></blockquote></div></div></div><br>
</div><br>