#12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): I'm very glad to see full laziness getting some attention. I've been aware of its deleterious effects for some time and have tried to spread awareness of it: * https://mail.haskell.org/pipermail/haskell- cafe/2013-February/106603.html * https://mail.haskell.org/pipermail/haskell- cafe/2015-December/122526.html * https://www.mail-archive.com/haskell-cafe@haskell.org/msg107101.html I have even asked whether it is an optimization worth performing at all, though I conclude that it is: * https://stackoverflow.com/questions/35115172/why-is-full-laziness-a -default-optimization/35115664 The full laziness transformation causes a lot of headaches and something ''really'' needs to be done about it. However I do not think this suggestion is the right approach. Why not tweak the transformation so that it only fires in cases that are guaranteed not to lead to memory leaks? That could be as simple as only hoisting bindings of monomorphic non-recursive datatypes. The proposed `nofloat` keyword is just adding additional complexity over a transformation which itself is introducing too much complexity. I'm very concerned about the idea. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12620#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler