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
