Heads-up: this one changes interface file formats, so you need a clean build.
Simon | -----Original Message----- | From: GHC [mailto:[email protected]] | Sent: 13 May 2015 09:02 | Cc: [email protected] | 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
