Heads-up: this one changes interface file formats, so you need a clean build.
Simon
| -----Original Message-----
| From: GHC [mailto:ghc-devs@haskell.org]
| Sent: 13 May 2015 09:02
| Cc: ghc-tickets@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 ):
|
| 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
