after reading current
http://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Concurrent-MVar...
haddocks
http://hackage.haskell.org/package/base-4.7.0.1/docs/System-Mem-Weak.html#t:...,
so i could understand the current and proposed apis, I'm +1 on this.
this would align with the api provided by weak pointer too.
On Fri, Nov 7, 2014 at 11:16 AM, Edward Kmett
We've had a ticket languishing in the trac for a couple of years that probably belongs as a libraries proposal:
https://ghc.haskell.org/trac/ghc/ticket/7285#comment:6
To summarize it here:
In base 4.6 addMVarFinalizer is deprecated in favour of mkWeakMVar of type
mkWeakMVar :: MVar a -> IO () -> IO (Weak (MVar a))
This type makes it inherently non-compositional. For instance, if we have a larger datatype T that contains an MVar somewhere inside then there in no way to define mkWeakT in terms of mkWeakMVar; instead, mkWeakT would have to be defined along the lines of
mkWeakT :: T a -> IO () -> IO (Weak (T a)) mkWeakT m@(MkT (MVar m#) _) f = IO $ \s -> case mkWeak# m# m f s of (# s1, w #) -> (# s1, Weak w #)
It would be better if the type of mkWeakMVar would change to
mkWeakMVar :: MVar a -> v -> Maybe (IO ()) -> IO (Weak v)
(i.e., following mkWeak rather than mkWeakPtr).
(The same comment goes for related functions such as mkWeakIORef.)
I'm personally in favor of the change, but wanted to seek wider community feedback.
Thoughts?
Discussion Period: 2 Weeks
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries