[GHC] #9858: Typeable instances should be kind-aware

[Simon Peyton Jones]

Heads-up: this one changes interface file formats, so you need a clean build.

Simon

|  -----Original Message-----
|  From: GHC [mailto:ghc-devs at haskell.org]
|  Sent: 13 May 2015 09:02
|  Cc: ghc-tickets at haskell.org
|  Subject: Re: [GHC] #9858: Typeable instances should be kind-aware
|  
|  #9858: Typeable instances should be kind-aware
|  -------------------------------------+--------------------------------
|  --
|  -------------------------------------+---
|          Reporter:  dreixel           |                   Owner:
|              Type:  bug               |                  Status:
|  closed
|          Priority:  highest           |               Milestone:
|  7.10.2
|         Component:  Compiler          |                 Version:  7.9
|        Resolution:  fixed             |                Keywords:
|  Operating System:  Unknown/Multiple  |            Architecture:
|   Type of failure:  None/Unknown      |  Unknown/Multiple
|        Blocked By:                    |               Test Case:
|   Related Tickets:                    |
|  typecheck/should_fail/T9858a,b,c;
|                                       |  should_run/T9858b
|                                       |                Blocking:
|                                       |  Differential Revisions:
|  Phab:D652
|  -------------------------------------+--------------------------------
|  --
|  -------------------------------------+---
|  
|  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/9858#comment:114>
|  GHC <http://www.haskell.org/ghc/>
|  The Glasgow Haskell Compiler