[Haskell-cafe] Mutable data within a (non-IO) monad
Gregory Crosswhite
gcross at phys.washington.edu
Fri Oct 2 23:00:48 EDT 2009
Sorry to reply to my own posting, but... AHA! I see now what's going
on. The purpose of the rank-2 qualifier is to prevent STRefs from
leaking outside of the runST call, and what the code does at the
lowest level is that it passes around a token "state" object to force
the compiler to correctly order the calculations. Very cool. :-)
Cheers,
Greg
On Oct 2, 2009, at 4:08 PM, Gregory Crosswhite wrote:
> Hey everyone,
>
> I am thinking about creating a particular data structure with an
> immutable and mutable version. The key of my problem is that I
> would like the user to be able to work with a mutable version of the
> data within a non-IO monad and then get an immutable value at the
> end, allowing them to do stateful-like computation in pure code.
> The key is that I need to enforce the ordering within the monad, but
> I can't do this using a state-transformer since the state doesn't
> actually change; instead, the data structure is internally
> modified, but the original pointer is kept to it.
>
> There are many data structures which already have this kind of
> functionality, such as STRefs and MArrays, however I am having
> trouble distilling from the source code what the best "trick" is to
> accomplish mutability of this form within a monad. There seem to be
> at least a couple of strategies: using "type-threading" with GHC's
> State# type, and using the ST monad with a rank-2 qualifier over the
> type of the state.
>
> Do you all have any thoughts on ways to solve this problem, and/or a
> high-level explanation of what is going behind the scenes with
> STRefs and MArrays?
>
> Thanks!
>
> - Greg
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
More information about the Haskell-Cafe
mailing list