<div dir="ltr">Also note linked from the global variables page on the wiki is: <a href="http://www.haskell.org/haskellwiki/Top_level_mutable_state">http://www.haskell.org/haskellwiki/Top_level_mutable_state</a><div><br></div>
<div>Important for the `unsafePerformIO` option is the NOINLINE pragma to ensure that only one global variable exists.  In the STM case it is also important to use `newTVarIO` rather then `unsafePerformIO $ atomically newTVar` which does not work.</div>
<div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 10:38 AM, Ben Foppa <span dir="ltr"><<a href="mailto:benjamin.foppa@gmail.com" target="_blank">benjamin.foppa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In my (limited) experience, there are two main solutions to this kind of problem:<div><ul><li>Dependency-injection, i.e. add the MVar as an explicit parameter to every function you use it in. This is ideal, but it's often a little cumbersome.</li>

<li><font face="courier new, monospace">unsafePerformIO</font>, i.e. just initialize it globally. I've never really had issues with this approach, if used sparingly and appropriately.</li></ul><div>This might also be relevant: <a href="http://www.haskell.org/haskellwiki/Global_variables" target="_blank">http://www.haskell.org/haskellwiki/Global_variables</a><br>

</div></div><div><br></div><div>Hope that helps!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Apr 17, 2014 at 10:34 AM, Brian Hurt <span dir="ltr"><<a href="mailto:bhurt@spnz.org" target="_blank">bhurt@spnz.org</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Thanks.  This helps.  I was right to mistrust the unsafePerformIO "solution".  :-)  What Haskell was telling me is that I need to think about the scope of the identifiers I'm allocating, and what guarantees I'm making.<div>


<br><div><br></div><div><br></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer <span dir="ltr"><<a href="mailto:danny.gratzer@gmail.com" target="_blank">danny.gratzer@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">New `MVar` has to return a different memory location every time and this is noticeable, it's not referentially transparent.<div>


<br></div><div>Consider what would happen if we made the transformation</div>

<div><br></div><div>     let a = newMVar 0</div><div>     let b = newMVar 0</div><div>     putMVar a 1</div><div>     readMVar b<br><div class="gmail_extra"><br></div><div class="gmail_extra">to</div><div class="gmail_extra">




<br></div><div class="gmail_extra">    let a = newMVar 0</div><div class="gmail_extra">         b = a</div><div class="gmail_extra">     ...</div><div class="gmail_extra"><br></div><div class="gmail_extra">If newMVar was referentially transparent, we can automatically share any of it's calls with same arguments since they're supposed to return the same thing everytime. Since it's not referentially transparent, back into the IO monad it goes.</div>




<div class="gmail_extra"><br></div><div class="gmail_extra">Also if you do that toplevel counter trick, you want NoInline otherwise GHC might just inline it at each occurrence and you'll end up with separate counters.<br clear="all">




<div><div dir="ltr"><div><br></div>Cheers,<div>Danny Gratzer</div></div></div></div></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<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></blockquote></div><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">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></blockquote></div><br></div>