Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

2022-04-05 Thread Erdi, Gergo via ghc-devs
PUBLIC Just so this isn't prematurely all lost, I went back and looked for this example. With the following two definitions: subsequences:: [a] -> [[a]] subsequences xs = [] : nonEmptySubsequences xs nonEmptySubsequences :: [a] -> [[a]] nonEmptySubsequences []

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

2022-04-05 Thread Zubin Duggal
Core Tidy also turns CoreUnfoldings to `OtherCon []` while zapping unfoldings. On 22/04/05 14:12, Sebastian Graf wrote: Top-level data structures tend to get OtherCon [] unfoldings when they are marked NOINLINE. KindRep bindings are one particular example, and they appear quite often, too.

Re[2]: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

2022-04-05 Thread Sebastian Graf
Top-level data structures tend to get OtherCon [] unfoldings when they are marked NOINLINE. KindRep bindings are one particular example, and they appear quite often, too. Why are KindReps are NOINLINE? Because (from Note [Grand plan for Typeable]) The KindReps can unfortunately get

Re: Avoiding `OtherCon []` unfoldings, restoring definitions from unfoldings

2022-04-05 Thread Ben Gamari
Simon Peyton Jones writes: > I don't think any top-level Ids should have OtherCon [] unfoldings? If > they do, can you give a repro case? OtherCon [] unfoldings usually mean "I > know this variable is evaluated, but I don't know what its value is. E.g >data T = MkT !a !a > f (MkT x y) =