Handling of unlifted types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling of unlifted types

Erik de Castro Lopo-34
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

but that results in:

    A representation-polymorphic type is not allowed here:
      Type: a
      Kind: TYPE r
    In the type of binder ‘x’

Am I barking up the wrong tree here? Any one have a clue on how I might
make progress on this?


Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Handling of unlifted types

Ben Gamari-2
Erik de Castro Lopo <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Handling of unlifted types

GHC - devs mailing list
In reply to this post by Erik de Castro Lopo-34
Suppose

  f1 :: forall (a :: TYPE LiftedPtrRep). a -> Closure
  f2 :: forall (a :: TYPE UnliftedPtrRep). a -> Closure
  f3 :: forall (a :: TYPE FloatRep). a -> Closure

f3 takes its argument in a floating point register, whereas f1 and f2 take their arguments in a pointer register; so you can't have a function polymorphic in all three.  See the paper (have you read it?)

You might think that f1 and f2 are more compatible, since they both take a pointer, but consider the call
        f1 (g x)
        f2 (h x)

For f1 we'll build a thunk for (g x) and pass it to f1.  For f2 we'll evaluate (h x) and pass the result to f2.  So the calls are different.

In short, there is a good reason that we can't be polymorphic here. You'll have to use three different functions.

Simon


|  -----Original Message-----
|  From: ghc-devs [mailto:[hidden email]] On Behalf Of Erik de
|  Castro Lopo
|  Sent: 05 February 2017 08:49
|  To: [hidden email]
|  Subject: Handling of unlifted types
|  
|  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
|  
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackage.hask
|  ell.org%2Ftrac%2Fghc%2Fbrowser%2Fincludes%2Frts%2Fstorage%2FInfoTables.h&dat
|  a=02%7C01%7Csimonpj%40microsoft.com%7Ca5585e761d5149d4f3c608d44da3f3dc%7C72f
|  988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636218813965987006&sdata=5ze3nbAjXYm
|  Ey7H6M4Imtyz7dVH1bjEtloUJWQ2ItWo%3D&reserved=0
|  
|  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
|  
|  but that results in:
|  
|      A representation-polymorphic type is not allowed here:
|        Type: a
|        Kind: TYPE r
|      In the type of binder ‘x’
|  
|  Am I barking up the wrong tree here? Any one have a clue on how I might make
|  progress on this?
|  
|  
|  Erik
|  --
|  ----------------------------------------------------------------------
|  Erik de Castro Lopo
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mega-
|  nerd.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ca5585e761d5149d4f3c608d
|  44da3f3dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636218813965987006&sd
|  ata=M8bvL%2BDEFYX7Sx%2FAipnRDBBtbFBMcAl7p3Rf86Hbe%2FA%3D&reserved=0
|  _______________________________________________
|  ghc-devs mailing list
|  [hidden email]
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ca5585e761d5149d4f3c608d44da3f3
|  dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636218813965987006&sdata=9AQ
|  mgEerIRrUeT%2BBRrGriMiAm2oJ7F9mQrMrBAPCQq0%3D&reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs