Erik de Castro Lopo <[email protected]> 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 > `SMALL_MUT_ARR_PTRS_*`. > > 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). Cheers, - Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
