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, <[email protected]> wrote: > Send ghc-devs mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Erik de Castro Lopo <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: Handling of unlifted types > Message-ID: > <DM2PR21MB002861CF4C24D71601C32B45AD430@DM2PR21MB0028. > namprd21.prod.outlook.com> > > 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:[email protected]] On Behalf Of Erik > de > | Castro Lopo > | Sent: 05 February 2017 08:49 > | To: [email protected] > | 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 > | [email protected] > | 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > ------------------------------ > > End of ghc-devs Digest, Vol 162, Issue 13 > ***************************************** >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
