Proposal: Change the signature of mkWeakMVar

Edward Kmett ekmett at gmail.com
Fri Nov 7 19:38:15 UTC 2014


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 <jwlato at gmail.com> 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 at gmail.com> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> 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/38b1371e/attachment.html>


More information about the Libraries mailing list