#11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria):
Where is the bug in the report?
Do you have a (hopefully small and self-contained) bit of code where you
I'm not convinced this is a bug. I've created this in response to this comment: https://phabricator.haskell.org/D1537#inline-12820. think “duh, obviously the compiler should be a allowed to eta-expand here”, but it does not? I can't tell if GHC should be allowed to eta-expand in my example, but the fact that it decided to eta-expand in a very similar situation where I didn't have mutually recursive functions suggests that it might be able to.
Do things are better if all the relevant code is in one module, with an explicit export list that does not include any of the functions you’d like to see eta-expanded?
Yes, it's enough to not export the functions I want eta-expanded. Unfortunately that's exactly what I want do in Phab:D1537 because I'm composing a computation from smaller pieces from several modules. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11146#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler