ghc-devs Digest, Vol 162, Issue 13
Demi Obenour
demiobenour at gmail.com
Wed Feb 8 03:52:30 UTC 2017
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, <ghc-devs-request at haskell.org> wrote:
> Send ghc-devs mailing list submissions to
> ghc-devs at 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 at haskell.org
>
> You can reach the person managing the list at
> ghc-devs-owner at 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 <simonpj at microsoft.com>
> To: Erik de Castro Lopo <mle+hs at mega-nerd.com>, "ghc-devs at haskell.org"
> <ghc-devs at haskell.org>
> Subject: RE: Handling of unlifted types
> Message-ID:
> <DM2PR21MB002861CF4C24D71601C32B45AD430 at 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:ghc-devs-bounces at haskell.org] On Behalf Of Erik
> de
> | Castro Lopo
> | Sent: 05 February 2017 08:49
> | To: ghc-devs at 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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ------------------------------
>
> End of ghc-devs Digest, Vol 162, Issue 13
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170207/a8799f8b/attachment.html>
More information about the ghc-devs
mailing list