Skip to content
  • Simon Peyton Jones's avatar
    Refactor tuple constraints · 130e93aa
    Simon Peyton Jones authored
    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
    130e93aa