Proposal: Change the signature of mkWeakMVar

[Carter Schonwald]

after reading current
<http://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Concurrent-MVar.html>
 haddocks
<http://hackage.haskell.org/package/base-4.7.0.1/docs/System-Mem-Weak.html#t:Weak>,
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 <ekmett at gmail.com> wrote:

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141107/3d00557c/attachment.html>