Suggested algorithm to control upper bound of space "leaks"
An idea for an algorithm to mitigate space "leaks".
Limited research (thus far) reveals that space "leaks" due to laziness are desireable function of the matrix of design choices and may be better automatically controlled in runtime (read both links to fully understand):
http://www.haskell.org/pipermail/haskell-cafe/2009-October/068382.html [[BR]] http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Proposes to fix to this bug (in theory):
http://hackage.haskell.org/trac/ghc/ticket/917
May you can cross-link from the bug, so people can read my links above to get a deeper understanding of why space "leaks" are really a feature, not a bug. And others can think about my idea at links above for a deterministic runtime upper bound solution (that proposes to be orthogonal to profiling and static optimization).
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |