Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Because generally ghc is doing a good-enough job. And it is doing that because long ago, ghc hq's war cry was "if ghc generates code that is slower than any other haskell implementation, it is a bug, and you should file a ticket". The failure of "avoid success at all cost" has meant shifting priorities, and those priorities tend to imply that alternative implementations can't keep up (not over the full range of ghc's offerings). So there is less "internal" competition, more "other stuff" on todo lists, and good enough just has to be good enough most of the time. But when it isn't, then not just people at ghc hq are still listening. And among all the other good stuff they keep adding, they also keep tweaking ghc's basics, in such a way that what would be hard to do now, may be easier to implement in future ghc versions. And for that, they need input about what they should focus on. And the advertised way of providing that input is the ticket tracker. For tickets, small examples are great - they often highlight aspects that are still present in real code, but are hard to see there (let alone reducing complex code to small test cases that help to fix those cases). In the particular example of unrolling, iirc, the issue was that ghc's internal representation does not easily lend itself to adding some counter that would keep the very modular optimizer from applying recursive unfoldings uselessly. Once that fundamental problem is fixed, I am optimistic that this useful optimization will be looked at again - if there is a ticket to remind everyone. And if -as I suspect- lots of ghc users find themselves doing loop unrolling/partial recursion unfoldings by hand (worker/wrapper for recursive functions is just such an example), they will up the priority on that ticket. You're right that ghc hq can't be everywhere, but they aren't the only ones who are invited to look at those tickets. And everytime someone starts on ghc hacking for some unrelated purpose, they need a small project to start on - well-defined tickets have a chance there. I'm not at all happy with Haskell optimists turning evangelists, but neither is it productive for Haskell pessimists to spread their frustration. There are useful ways for both sides to contribute to the Haskell world, can we focus on those ways? Claus