<div dir="auto">What if the function is strict? If the function is strict, then no think is required.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 7, 2017 7:20 AM, <<a href="mailto:ghc-devs-request@haskell.org">ghc-devs-request@haskell.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ghc-devs mailing list submissions to<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:ghc-devs-request@haskell.org">ghc-devs-request@haskell.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:ghc-devs-owner@haskell.org">ghc-devs-owner@haskell.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ghc-devs digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. RE: Handling of unlifted types (Simon Peyton Jones)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 7 Feb 2017 11:18:09 +0000<br>
From: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>><br>
To: Erik de Castro Lopo <<a href="mailto:mle%2Bhs@mega-nerd.com">mle+hs@mega-nerd.com</a>>, "<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>"<br>
<<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>><br>
Subject: RE: Handling of unlifted types<br>
Message-ID:<br>
<<a href="mailto:DM2PR21MB002861CF4C24D71601C32B45AD430@DM2PR21MB0028.namprd21.prod.outlook.com">DM2PR21MB002861CF4C24D71601C3<wbr>2B45AD430@DM2PR21MB0028.<wbr>namprd21.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Suppose<br>
<br>
f1 :: forall (a :: TYPE LiftedPtrRep). a -> Closure<br>
f2 :: forall (a :: TYPE UnliftedPtrRep). a -> Closure<br>
f3 :: forall (a :: TYPE FloatRep). a -> Closure<br>
<br>
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?)<br>
<br>
You might think that f1 and f2 are more compatible, since they both take a pointer, but consider the call<br>
f1 (g x)<br>
f2 (h x)<br>
<br>
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.<br>
<br>
In short, there is a good reason that we can't be polymorphic here. You'll have to use three different functions.<br>
<br>
Simon<br>
<br>
<br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@<wbr>haskell.org</a>] On Behalf Of Erik de<br>
| Castro Lopo<br>
| Sent: 05 February 2017 08:49<br>
| To: <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| Subject: Handling of unlifted types<br>
|<br>
| Hi all,<br>
|<br>
| I'm working on pulling the core parts of Joachim Breitner's ghc-heap-view<br>
| library into GHC. The WIP Phab review is here:<br>
|<br>
| <a href="https://phabricator.haskell.org/D3055" rel="noreferrer" target="_blank">https://phabricator.haskell.<wbr>org/D3055</a><br>
|<br>
| Currently that library has a function:<br>
|<br>
| getClosureData :: a -> IO Closure<br>
|<br>
| which works fine for lifted types. However, some of the supported closure<br>
| types in<br>
|<br>
|<br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackage.hask" rel="noreferrer" target="_blank">https://na01.safelinks.<wbr>protection.outlook.com/?url=<wbr>http%3A%2F%2Fhackage.hask</a><br>
| <a href="http://ell.org" rel="noreferrer" target="_blank">ell.org</a>%2Ftrac%2Fghc%<wbr>2Fbrowser%2Fincludes%2Frts%<wbr>2Fstorage%2FInfoTables.h&dat<br>
| a=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsof<wbr>t.com</a>%<wbr>7Ca5585e761d5149d4f3c608d44da3<wbr>f3dc%7C72f<br>
| 988bf86f141af91ab2d7cd011db47%<wbr>7C1%7C0%7C636218813965987006&<wbr>sdata=5ze3nbAjXYm<br>
| Ey7H6M4Imtyz7dVH1bjEtloUJWQ2It<wbr>Wo%3D&reserved=0<br>
|<br>
| actually refer to unlifted types, like the `MUT_ARR_PTRS_*` and<br>
| `SMALL_MUT_ARR_PTRS_*`.<br>
|<br>
| I've had a look at the levity polymorphism stuff implemented in ghc 8.0 and<br>
| came up with a new type for `getClosureData`:<br>
|<br>
| getClosureData :: forall (r :: RuntimeRep) (a :: TYPE r). a -> IO<br>
| Closure<br>
|<br>
| but that results in:<br>
|<br>
| A representation-polymorphic type is not allowed here:<br>
| Type: a<br>
| Kind: TYPE r<br>
| In the type of binder ‘x’<br>
|<br>
| Am I barking up the wrong tree here? Any one have a clue on how I might make<br>
| progress on this?<br>
|<br>
|<br>
| Erik<br>
| --<br>
| ------------------------------<wbr>------------------------------<wbr>----------<br>
| Erik de Castro Lopo<br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mega-" rel="noreferrer" target="_blank">https://na01.safelinks.<wbr>protection.outlook.com/?url=<wbr>http%3A%2F%2Fwww.mega-</a><br>
| <a href="http://nerd.com" rel="noreferrer" target="_blank">nerd.com</a>%2F&data=02%7C01%<wbr>7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%<wbr>7Ca5585e761d5149d4f3c608d<br>
| 44da3f3dc%<wbr>7C72f988bf86f141af91ab2d7cd011<wbr>db47%7C1%7C0%<wbr>7C636218813965987006&sd<br>
| ata=M8bvL%2BDEFYX7Sx%<wbr>2FAipnRDBBtbFBMcAl7p3Rf86Hbe%<wbr>2FA%3D&reserved=0<br>
| ______________________________<wbr>_________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell" rel="noreferrer" target="_blank">https://na01.safelinks.<wbr>protection.outlook.com/?url=<wbr>http%3A%2F%2Fmail.haskell</a><br>
| .org%2Fcgi-bin%2Fmailman%<wbr>2Flistinfo%2Fghc-<br>
| devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40<wbr>microsoft.com</a>%<wbr>7Ca5585e761d5149d4f3c608d44da3<wbr>f3<br>
| dc%<wbr>7C72f988bf86f141af91ab2d7cd011<wbr>db47%7C1%7C0%<wbr>7C636218813965987006&sdata=9AQ<br>
| mgEerIRrUeT%<wbr>2BBRrGriMiAm2oJ7F9mQrMrBAPCQq0<wbr>%3D&reserved=0<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br>
<br>
------------------------------<br>
<br>
End of ghc-devs Digest, Vol 162, Issue 13<br>
******************************<wbr>***********<br>
</blockquote></div></div>