Stylistically base tends to not get into the business of defining these sort of one-off convenience classes and I personally think it'd be hard for users to find/understand. -Edward On Fri, Nov 7, 2014 at 1:53 PM, John Lato wrote:

I think this is a good idea, but I wonder if we could do a bit better?

Weaks are already implemented as key/value pairs, what we really need is a way to specify that a data value is a primitive that is appropriate to be used as a weak key. Would it make sense to introduce a new typeclass:

class WeakKey k where mkWeakOn :: k -> v -> Maybe (IO ()) -> IO (Weak v)

Then we could have implementations for MVar, IORef, TVar etc.

John L.

On Fri Nov 07 2014 at 9:02:25 AM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Adding the other variants seems to make sense to me. TVar has its low-level definition in GHC.Conc, so it is available to base to define. -Edward On Fri, Nov 7, 2014 at 3:02 PM, John Lato wrote:

I find it hard to believe that users who understand weak refs would have trouble understanding this class, but that's fine. If you think a bunch of monomorphic variants are better I don't want to argue the point.

It's a definite need though, since otherwise users have to define these by hand, so +1.

Could we also please add versions for the stm types? I've needed at least one of them in the past.