<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">One significant problem is that {-# INLINE #-} functions are not actually always inlined! Specifically, if an inline-function is not passed all of its arguments, it will not be inlined. This poses a problem for levity-polymorphic functions, and GHC already does some special handling of the few levity-polymorphic primitives, in case they are ever used without all of their arguments.<div class=""><br class=""></div><div class="">As for boxing levity-polymorphic arguments: that's plausible, but then I think you've defeated the programmer's intended aim.</div><div class=""><br class=""></div><div class="">The solution to me is some kind of so-called <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/14917#note_151678" class="">template polymorphism</a>. This might work, but it would take a fair amount of design work first.</div><div class=""><br class=""></div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 7, 2021, at 7:36 PM, Clinton Mead <<a href="mailto:clintonmead@gmail.com" class="">clintonmead@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi All</div><div class=""><br class=""></div><div class="">Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough to put it here. </div><div class=""><br class=""></div><div class=""><a href="https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/exts/levity_polymorphism.html" class="">Section 6.4.12.1</a> 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. </div><div class=""><br class=""></div><div class="">However, if such a function is <font face="monospace" class="">{-# INLINE #-}</font> or<font face="monospace" class=""> {-# INLINABLE #-}</font> 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).</div><div class=""><br class=""></div><div class="">The only sticking point to this that I could find was that <a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/pragmas.html#inline-pragma" class="">GHC will only inline the function if it is fully applied</a>, 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. </div><div class=""><br class=""></div><div class="">It seems to me we're okay as long as the following three things aren't true simultaneously:</div><div class=""><br class=""></div><div class="">1. Blah has levity polymorphic arguments</div><div class="">2. Blah is exported</div><div class="">3. Blah is not inline</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">"Blah has levity polymorphic arguments, is exported, and is not inline. Please either remove levity polymorphic arguments, not export it or add an <font face="monospace" class="">{-# INLINE #-}</font> or<font face="monospace" class=""> {-# INLINABLE #-}</font> pragma.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Thanks,<br class="">Clinton</div><div class=""><br class=""></div></div>
_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></blockquote></div><br class=""></div></body></html>