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

[Clinton Mead]

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

Temporary Outage

[Ben Gamari]

Hi all,

You may notice that currently there are numerous CI failures due to
apparent network issues. This appears to be due to a network outage on
the part of our hosting providing. Further updates are available from
Packet [1]. Hopefully the issue will be resolved within the next few
hours.

Cheers,

- Ben


[1] https://status.equinixmetal.com/


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Perf backtrace support.

[Andreas Klebinger]

Hello Devs,

as some of you know I've recently been working on #8272.
The goal being to use the machine stack register for the STG stack as a
means to
get perf backtraces. I've succeeded in making a branch that works for
the first
part but have so far been unable to get perf to generate proper back traces.

For various reasons I will stop looking at that particular issue. So if
anyone feels
interested in figuring out where the interaction between our dwarf info
and perf
unwinding the stack goes wrong please take a look! There is more
information on
the ticket.

Cheers

Andreas


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs