[Proposal] Unify various specialized mkWeak functions in base?
Cheng Shao
astrohavoc at gmail.com
Wed Nov 11 21:34:00 UTC 2020
Hi everyone,
In System.Mem.Weak we have an mkWeak function to create weak pointers. But
we
also have a lot of specialized mkWeak* functions, e.g. mkWeakIORef,
mkWeakThreadId, etc, to ensure that we actually pass the unlifted closure
instead of the lifted one as the key to the underlying mkWeak# primop.
The various specialized mkWeak* functions' signatures don't have a coherent
style. Some functions like mkWeakIORef always take a Haskell finalizer
argument,
while mkWeakThreadId doesn't take a finalizer argument at all. This is
troublesome for users since:
* Sometimes a user doesn't want to attach a finalizer at all. They could
pass a
"pure ()" dummy finalizer, but that'll still come with a minor bit of extra
runtime overhead
* For mkWeakThreadId, they may want to attach a finalizer. The runtime
supports
it, but the type signature doesn't say so.
Of course, they can always add a few extensions and call mkWeak# as they
wish,
but it would be nicer if we have a uniform API to allow a Haskell finalizer
to
be added optionally. The simplest API could be something like (forgive my
terrible naming):
class WeakKey k where
mkWeakWithRealKey :: WeakKey k => k -> v -> Maybe (IO ()) -> IO (Weak v)
The WeakKey class is just a way of exposing the unlifted field from a single
datacon wrapper type, and I think this can be useful for other purposes as
well,
so maybe we can do something like:
class Unlift a where
type Unlifted a :: TYPE 'UnliftedRep
unlift :: a -> Unlifted a
mkWeakWithRealKey :: Unlift k => k -> v -> Maybe (IO ()) -> IO (Weak v)
Thanks for reading so far, what are your thoughts on this? The proposed
extended
interfaces can be easily implemented in 3rd-party packages, but it would be
nice
to add to base.
Cheers,
Cheng Shao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20201111/00a261b1/attachment-0001.html>
More information about the Libraries
mailing list