[Haskell-cafe] Stupid newbie question of the day: why is newMVar in the IO monad?
fryguybob at gmail.com
Thu Apr 17 14:44:44 UTC 2014
Also note linked from the global variables page on the wiki is:
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.
On Thu, Apr 17, 2014 at 10:38 AM, Ben Foppa <benjamin.foppa at gmail.com>wrote:
> In my (limited) experience, there are two main solutions to this kind of
> - 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
> - unsafePerformIO, i.e. just initialize it globally. I've never really
> had issues with this approach, if used sparingly and appropriately.
> This might also be relevant:
> Hope that helps!
> On Thu, Apr 17, 2014 at 10:34 AM, Brian Hurt <bhurt at spnz.org> wrote:
>> 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.
>> On Thu, Apr 17, 2014 at 10:26 AM, Danny Gratzer <danny.gratzer at gmail.com>wrote:
>>> New `MVar` has to return a different memory location every time and this
>>> is noticeable, it's not referentially transparent.
>>> Consider what would happen if we made the transformation
>>> let a = newMVar 0
>>> let b = newMVar 0
>>> putMVar a 1
>>> readMVar b
>>> let a = newMVar 0
>>> b = a
>>> 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.
>>> 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
>>> Danny Gratzer
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe