#11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 nomeata): So you suggest that the desired semantics is that a trivial `let` should guarantee sharing, right? In this case, transforming `let x = y in foo x` to `foo y` is not a valid transformation any more. Unless we can guarantee that `foo y` evaluates `y` only once ''or'' unless we can guarantee that `y` is shared anyways. Assuming we do not want to drag strictness annotations into the semantics, we cannot do that! (But maybe dragging them in is fine?) The rule “a trivial `let` does not guarantee sharing” allows the the above transformation unconditionally, but shifts the onus to the earlier simplification of the RHS. Is that less hairy there? Not sure... Or maybe, as a third option, we should flag a variable with a bit of information that indicates whether it is shared (and safe to evaluate multiple times). How is that different from the demand annotation? The demand annotation says something about how it ''is'' used, while this flag contains information about how the variable is going to be created (with or without an update frame) and then guides how it ''can'' be used. I don’t see all the consequences, of course, but such a variable would in many cases behave more like a possibly costly expression, i.e. should not be duped, not be floated into a let etc. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11731#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler