Why can't arguments be levity polymorphic for inline functions?

[Ben Gamari]

Clinton Mead <clintonmead at gmail.com> writes:

> 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
> <https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/exts/levity_polymorphism.html>
> 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
> <https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/pragmas.html#inline-pragma>,
> 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
>
In my mind the fundamental problem with this approach is that it means
that a program's acceptance by the compiler hinges upon pragmas.
This is a rather significant departure from the status quo, where one
can remove all pragmas and still end up with a well-formed program. 
In this sense, pragmas aren't really part of the Haskell language but
are rather bits of interesting metadata that the compiler may or may not
pay heed to.

Given that levity polymorphic functions have rather deep implications on
compilation strategy, I suspect that the cleanest path to allowing it
would be to further extend the type system (for instance, with a new
"macro expanding" arrow notion).

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211008/b0febb7b/attachment.sig>