Re: ghc-devs Digest, Vol 162, Issue 13

What if the function is strict? If the function is strict, then no think is required. Indeed, I see unsafe casts from unlifted to lifted types in at least two places in GHC (the bytecode linker and code related to hs_put_mvar). The only absolute limitation is GC, which doesn't care either way. One caveat is that such a function CANNOT be called as if it wasn't levity-polymorphic, because of precisely the issue you mentioned — the caller, not the callee, is responsible for evaluating the arguments. So this would need extensions to the kind system, as well as special handling in the compiler. On Feb 7, 2017 7:20 AM, wrote:

Send ghc-devs mailing list submissions to ghc-devs@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs or, via email, send a message with subject or body 'help' to ghc-devs-request@haskell.org

You can reach the person managing the list at ghc-devs-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of ghc-devs digest..."

Today's Topics:

1. RE: Handling of unlifted types (Simon Peyton Jones)

----------------------------------------------------------------------

Message: 1 Date: Tue, 7 Feb 2017 11:18:09 +0000 From: Simon Peyton Jones To: Erik de Castro Lopo , "ghc-devs@haskell.org" Subject: RE: Handling of unlifted types Message-ID:

Content-Type: text/plain; charset="utf-8"

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:ghc-devs-bounces@haskell.org] On Behalf Of Erik de | Castro Lopo | Sent: 05 February 2017 08:49 | To: ghc-devs@haskell.org | 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%7Ca5585e761d5149d4f3c608d44da3 f3dc%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 | ghc-devs@haskell.org | 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

------------------------------

Subject: Digest Footer

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

------------------------------

End of ghc-devs Digest, Vol 162, Issue 13 *****************************************