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@haskell.org> 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 <simonpj@microsoft.com>
To: Erik de Castro Lopo <mle+hs@mega-nerd.com>, "ghc-devs@haskell.org"
        <ghc-devs@haskell.org>
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: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%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
|  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
*****************************************