Note that you can use Typed Template Haskell as a workaround, e.g.

f :: forall r (a :: TYPE r). Code Q (a -> a)
f = [||\x -> x||]

In the future this might be integrated better with the restriction
polymorphism checking:

https://gitlab.haskell.org/ghc/ghc/-/issues/18170
https://gitlab.haskell.org/ghc/ghc/-/wikis/FixedRuntimeRep#typed-template-haskell

On Fri, Oct 8, 2021 at 5:19 PM Simon Peyton Jones via ghc-devs
<ghc-devs@haskell.org> wrote:
>
> We do have a few such functions, and we give them a “compulsory unfolding” 
> which means they MUST be inlined at EVERY call site.  But
>
>
>
> Usually if a module exports a function, it generates code for that function. 
> But for these guys it can’t.   We don’t have a mechanism for *not* generating 
> code for user-defined functions.  We could add an INLINE-COMPULSORY pragma 
> perhaps.
> Even then we’d have to check that every call of such a function is applied to 
> enough arguments to get rid of all levity/representation polymorphism; so 
> that when it is inlined all is good. It’s not clear how to do that in general.
>
>
>
> That’s the kind of thing Richard means by “templates”.
>
>
>
> Simon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point 
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com 
> instead.  (For now, it just forwards to simo...@microsoft.com.)
>
>
>
> From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Clinton Mead
> Sent: 08 October 2021 00:37
> To: ghc-devs@haskell.org
> Subject: Why can't arguments be levity polymorphic for inline functions?
>
>
>
> Hi All
>
>
>
> Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough 
> to put it here.
>
>
>
> Section 6.4.12.1 of the GHC user manual points out, if we allowed levity 
> polymorphic arguments, then we would have no way to compile these functions, 
> because the code required for different levites is different.
>
>
>
> However, if such a function is {-# INLINE #-} or {-# INLINABLE #-} there's no 
> need to compile it as it's full definition is in the interface file. Callers 
> can just compile it themselves with the levity they require. Indeed callers 
> of inline functions already compile their own versions even without levity 
> polymorphism (for example, presumably inlining function calls that are known 
> at compile time).
>
>
>
> The only sticking point to this that I could find was that GHC will only 
> inline the function if it is fully applied, which suggests that the 
> possibility of partial application means we can't inline and hence need a 
> compiled version of the code. But this seems like a silly restriction, as we 
> have the full RHS of the definition in the interface file. The caller can 
> easily create and compile it's own partially applied version. It should be 
> able to do this regardless of levity.
>
>
>
> It seems to me we're okay as long as the following three things aren't true 
> simultaneously:
>
>
>
> 1. Blah has levity polymorphic arguments
>
> 2. Blah is exported
>
> 3. Blah is not inline
>
>
>
> If a function "Blah" is not exported, we shouldn't care about levity 
> polymorphic arguments, because we have it's RHS on hand in the current module 
> and compile it as appropriate. And if it's inline, we're exposing it's full 
> RHS to other callers so we're still fine also. Only when these three 
> conditions combine should we give an error, say like:
>
>
>
> "Blah has levity polymorphic arguments, is exported, and is not inline. 
> Please either remove levity polymorphic arguments, not export it or add an  
> {-# INLINE #-} or {-# INLINABLE #-} pragma.
>
>
>
> I presume however there are some added complications that I don't understand, 
> and I'm very interested in what they are as I presume they'll be quite 
> interesting.
>
>
>
> Thanks,
> Clinton
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to