As I have stated, I believe there are many use cases, even to the common worker/wrapper pattern that seeks to reduce the amount of parameter
#12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): passing by enclosing a recursive worker closure inside a wrapper; any gains from this pattern could be cancelled and more if the wrapped enclosure is less efficient. Let me say what I ''think'' you are saying. Consider {{{ f x p q = let g y = ...g y'...x... in (g p, g q) }}} Left as-is we allocate a closure for `g` every time we call `f`. But instead we could lambda-lift `g`: {{{ g2 x y = ...g2 x y'...x... f x p q = (g2 x p, g2 x q) }}} Now we don't allocate a closure for `g`. That is good. Is this what you mean? We don't want to do this in general, early in optimisation, because we get huge benefits from being able to "see" the binding site of `g`'s free variable `x`. But these benefits are over when it comes to code generation. So we have experimented with so-called "late lambda lifting" (LLF). There's a whole wiki page about it: [wiki:LateLamLift]. It can be a real win. One obstacle to LLF is, ironically, that it can destroy join points (see the wiki page). A second benefit of Luke's new join-point work is that it becomes much easier to ensure that LLF doesn't destroy join points, and thus renders it much more practical. I think Luke will turn his attention to it once join points are solidly in. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12808#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler