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 simonpj@microsoft.com will cease to work.  Use simon.peytonjones@gmail.com instead.  (For now, it just forwards to simonpj@microsoft.com.)

From: ghc-devs <ghc-devs-bounces@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