Unlifted primop types

David Feuer david.feuer at gmail.com
Thu Aug 23 21:52:01 UTC 2018


Weak pointers to unlifted heap objects are the opposite of dodgy! We have
base library functions (e.g., Data.IORef.mkWeakIORef) for creating weak
references to lifted objects that *actually* create references to the
underlying unlifted objects instead. This is much more reliable, because
the wrapper (e.g., the STRef constructor) could be stripped away by
worker-wrapper, while the underlying object (e.g., the MutVar#) won't be.

On Thu, Aug 23, 2018, 5:43 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Gah.  We have no way to be polymorphic over all pointers (both lifted and
> unlifted) but not over Int# etc.
>
>
>
> As you say, this is too much of a special case to make an invasive change.
>
>
>
> I’m quite dubious about making weak poitners to unlifted heap-allocated
> objects.  I can’t say it’s wrong but it feels dodgy to me.
>
>
>
> Simon
>
>
>
> *From:* David Feuer <david.feuer at gmail.com>
> *Sent:* 22 August 2018 14:59
> *To:* Ben Gamari <ben at smart-cactus.org>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; David Feuer <
> david at well-typed.com>; ghc-devs <ghc-devs at haskell.org>
> *Subject:* Re: Unlifted primop types
>
>
>
> The problem is that this also accepts things that aren't pointers at all!
> We could fix that *for primops* by changing RuntimeRep to something like
>
>
>
> data RuntimeRep
>
>   = PtrRep Liftedness
>
>    | ...
>
>
>
> But that would only work for primops (at least for now) so it may not be
> worth the breakage.
>
>
>
> On Wed, Aug 22, 2018, 7:45 AM Ben Gamari <ben at smart-cactus.org> wrote:
>
> Simon Peyton Jones <simonpj at microsoft.com> writes:
>
> > |  Huh! It looks like what we currently do for some primops is just use a
> > |  totally bogus kind. For example, mkWeak# will happily accept an Int#
> as
> > |  its first argument.
> >
> > Well, I see
> >   primop  MkWeakOp "mkWeak#" GenPrimOp
> >      o -> b -> (State# RealWorld -> (# State# RealWorld, c #))
> >
> > and I believe (from Ben's message) that the "o" means "open type
> variable",
> > which is the old terminology for what we now call levity-polymorphic.
> >
> Right; currently (largely for historical reasons) we use `o` to
> accommodate cases that accept both lifted and unlifted pointers.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180823/3c0348be/attachment.html>


More information about the ghc-devs mailing list