Handling of unlifted types

Ben Gamari ben at smart-cactus.org
Sun Feb 5 16:34:28 UTC 2017

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Hi all,
> I'm working on pulling the core parts of Joachim Breitner's
> ghc-heap-view library into GHC. The WIP Phab review is here:
>     https://phabricator.haskell.org/D3055
> Currently that library has a function:
>     getClosureData :: a -> IO Closure
> which works fine for lifted types. However, some of the supported
> closure types in 
>     http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/InfoTables.h
> actually refer to unlifted types, like the `MUT_ARR_PTRS_*` and
> I've had a look at the levity polymorphism stuff implemented in ghc 8.0
> and came up with a new type for `getClosureData`:
>     getClosureData :: forall (r :: RuntimeRep) (a :: TYPE r). a -> IO Closure
Unfortunately I'm not sure that the sort of polymorphism that you need
is possible at the moment. To see why, consider a few of the kinds that
this function as-written might take,

 1. Double# :: TYPE 'DoubleRep
 2. Int     :: TYPE 'LiftedRep
 3. Array#  :: TYPE 'UnliftedRep

What you want here, I believe, is to allow getClosureData to accept (2)
and (3). This should in principle be fine; afterall they are both
represented at runtime by a pointer. However, (1) has a much different
representation (being passed in a floating point register) and currently
we can't distinguish (1) from (2) and (3) in the kind system.
Consequently, we aren't able to provide this sort of sort of
polymorphism since there is no single calling convention that could be
used with such a function.

At the moment I think the best you could do would be to provide an
implementation for each supported RuntimeRep (either multiple functions
or typeclass overloaded).


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170205/cef8ef96/attachment.sig>

More information about the ghc-devs mailing list