
#13080: Memory leak caused by nested monadic loops -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 Feuerbach): Simon: as a matter of fact, I would expect all the calls to expensive to be recomputed. I think most programmers would interpret the above code as {{{ while (1) { for (n = 1; 1 <= 10000; n++) { print(expensive(n)); } } }}} If I wanted the calls to expensive to be shared, I would probably put them into a list. (Of course, a similar piece of code could be intended for `m = []`; but based on `print`, it looks like something intended for an `IO`-like monad.) I do understand the tradeoffs involved, and I'm not saying that this should be obvious to the compiler. I'm just saying that this might not be the most convincing example where the current behavior is the one a programmer would expect. What if a programmer could annotate variables (like `worker` or `poll`) as "function-like" vs "value-like"? "Function-like" means "I don't care about this value, feel free to recompute it" and "value-like" means "please cache it if possible". -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13080#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler