[GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage

[GHC]

#10359: Tuple constraint synonym led to asymptotic performance lossage
-------------------------------------+-------------------------------------
        Reporter:  axch              |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.6.3
      Resolution:                    |                Keywords:
Operating System:  Linux             |            Architecture:  x86_64
 Type of failure:  Runtime           |  (amd64)
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"130e93aab220bdf14d08028771f83df210da340b/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="130e93aab220bdf14d08028771f83df210da340b"
 Refactor tuple constraints

 Make tuple constraints be handled by a perfectly ordinary
 type class, with the component constraints being the
 superclasses:
     class (c1, c2) => (c2, c2)

 This change was provoked by

   #10359  inability to re-use a given tuple
           constraint as a whole

   #9858   confusion between term tuples
           and constraint tuples

 but it's generally a very nice simplification. We get rid of
  -  In Type, the TuplePred constructor of PredTree,
     and all the code that dealt with TuplePreds
  -  In TcEvidence, the constructors EvTupleMk, EvTupleSel

 See Note [How tuples work] in TysWiredIn.

 Of course, nothing is ever entirely simple. This one
 proved quite fiddly.

 - I did quite a bit of renaming, which makes this patch
   touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.

 - I made constraint tuples known-key rather than wired-in.
   This is different to boxed/unboxed tuples, but it proved
   awkward to have all the superclass selectors wired-in.
   Easier just to use the standard mechanims.

 - While I was fiddling with known-key names, I split the TH Name
   definitions out of DsMeta into a new module THNames.  That meant
   that the known-key names can all be gathered in PrelInfo, without
   causing module loops.

 - I found that the parser was parsing an import item like
       T( .. )
   as a *data constructor* T, and then using setRdrNameSpace to
   fix it.  Stupid!  So I changed the parser to parse a *type
   constructor* T, which means less use of setRdrNameSpace.

   I also improved setRdrNameSpace to behave better on Exact Names.
   Largely on priciple; I don't think it matters a lot.

 - When compiling a data type declaration for a wired-in thing like
   tuples (,), or lists, we don't really need to look at the
   declaration.  We have the wired-in thing!  And not doing so avoids
   having to line up the uniques for data constructor workers etc.
   See Note [Declarations for wired-in things]

 - I found that FunDeps.oclose wasn't taking superclasses into
   account; easily fixed.

 - Some error message refactoring for invalid constraints in TcValidity
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10359#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler