#7662: Improve GC of mutable objects -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 7.7 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 rwbarton): I think this has been discussed elsewhere too, but I don't understand how the above could be consistent with Haskell's semantics. What if I define {{{#!hs upperize :: SomeType -> SomeType upperize s = s { y = toUpper (y s) } }}} Obviously this needs to allocate a new `SomeType` closure on the heap, but if the `IORef Int` is completely unpacked into a mutable field of `SomeType` closures, then the new closure can't share `x` with the old closure. In general just constructing a `SomeType` value would have the observable effect of creating a new mutable cell and so would have to live in IO. In short, ML's records with mutable fields have identity, and so are quite different than just sticking an `IORef` inside a record in Haskell. In Haskell the `IORef` itself has identity (and thus is created and accessed through IO actions) but the record `SomeType` does not. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7662#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler