[Haskell-cafe] save/restore of STRef state

[Job Vranish]

On Sat, Feb 27, 2010 at 11:53 AM, Andrew Coppin <andrewcoppin at btinternet.com
> wrote:
>
>
> If you use something like the State or Reader monad, it becomes trivial to
> temporarily modify the carried state. But maybe something like this is
> occasionally useful. (In particular, it seems to allow you to restore to a
> point not necessarily matching the most recent save.)


Yeah, in cases where you only need "references" to values of the same type,
then a Map in a state or Reader works really well.

But in my case I need to reference values of several different types, which
would make things messy in a state monad, and saving/restoring even messier.
I'm also using MonadFix quite a bit and a Map in a State monad was a lot
harder to make lazy (in my case, sometimes it's not to bad).


> Deriving the Eq instance for ContextRef means that it will compare the key
> *and* the IORef. Which gives the right answer, but seems rather redundant.
> Comparing the key alone should be sufficient.


Agree, will fix.

Why an IORef? Why not an STRef? Then you won't need unsafeIOToST. (And since
> the type system forces a ContextRef to exist in only one state thread,
> worrying about thread isolation with atomicModifyIORef seems unecessary.)
>

I use the IORefs because I wanted to use mkWeakIORef (maybe mkWeak would
work just as well?) and atomicModifyIORef. The thread isolation is needed
because of the the finalizers that clean out the map when the references get
GC'd.

Although, it _is_ kinda ugly. I'm thinking I might switch back STRefs and
just use unsafeCoerce *flinch* when I want to use atomicModifyIORef. (IORef
is just a newtype around STRef)


> Using a state monad with a mutable structure as the state looks highly
> dubious. (The whole point of a state monad is, after all, to avoid needing
> to mutate stuff.) I can see 2 calls to "get", but none to "put". I would
> suggest you either use a reader monad with mutable state, or a state monad
> with immutable state. One or the other. (Personally, I'd go for the latter.)
>

Yeah, I'll switch to Reader, but the state needs to be mutable so that the
finalizers can get to it.


> I'm also not 100% sure how the saving and restoring part works. Map Int (IO
> (IO ())) sounds fruity though.
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Thanks for the feedback :)

- Job
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100227/79cc64ca/attachment.html