<br><br><div class="gmail_quote">On Sat, Feb 27, 2010 at 11:53 AM, Andrew Coppin <span dir="ltr"><<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br></div>
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.)</blockquote>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"></blockquote>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.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">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).</div>
<div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br></div>
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.</blockquote><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote>Agree, will fix.</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.)<br>
</blockquote><div><br></div><div>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. </div>
<div><br></div><div>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)</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.)<br>
</blockquote><div><br></div><div>Yeah, I'll switch to Reader, but the state needs to be mutable so that the finalizers can get to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm also not 100% sure how the saving and restoring part works. Map Int (IO (IO ())) sounds fruity though.<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>
</blockquote></div><br><div>Thanks for the feedback :)</div><div><br></div><div>- Job</div>