#12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch 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): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): Facundo, your work has exposed some woolly thinking on my part, and I think we need to take a step back to revisit some of our earlier design decisions. I fear that we are now piling hack upon hack and accumulating technical debt that we will later regret. In particular, the desire to accomodate references to local closed defintitions (seee Trac #11656) has led to a raft of unexpected complexity: * We need the `tcg_static_wc` stuff anyway. * The `FloatOut` pass needs special extra stuff, and must always be run. * Similary the SPT construction needs to find all those top-level `StaticPtr` applications. * Now we discover that sometimes nested `StaticPtr` is fine, which leads to further complexity in your patch. All this sounds fragile. We see all the uses of `static` so it seems odd to have to rediscover them when we are constructing the SPT. How important is #11656, really? After all, you can always write those local closed defns at top level! If we recanted on that we could: * Do all the floating work in the type checker (we are doing it alrady with `tcg_static_wc`, prettty much) * And then we'd be done! This seems attractive to me. When in a hole, stop digging! There's always a tradeoff between compiler complexity and language expressiveness. Yes we ''can'' do everything. But life is short, and if we spend time doing X it means we don't have time to Y. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12622#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler