[GHC] #12622: Unboxed static pointers lead to missing SPT entries

[GHC]

#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