From 130e93aab220bdf14d08028771f83df210da340b Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Mon, 11 May 2015 23:19:14 +0100 Subject: 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 --- .../tests/typecheck/should_fail/tcfail157.stderr | 24 +++++++++++----------- 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'testsuite/tests/typecheck/should_fail/tcfail157.stderr') diff --git a/testsuite/tests/typecheck/should_fail/tcfail157.stderr b/testsuite/tests/typecheck/should_fail/tcfail157.stderr index acdc7df8cf..113e0cc67e 100644 --- a/testsuite/tests/typecheck/should_fail/tcfail157.stderr +++ b/testsuite/tests/typecheck/should_fail/tcfail157.stderr @@ -1,12 +1,12 @@ - -tcfail157.hs:27:10: - Variable ‘b’ occurs more often than in the instance head - in the constraint: E m a b - (Use UndecidableInstances to permit this) - In the instance declaration for ‘Foo m (a -> ())’ - -tcfail157.hs:27:10: - Variable ‘b’ occurs more often than in the instance head - in the constraint: Foo m b - (Use UndecidableInstances to permit this) - In the instance declaration for ‘Foo m (a -> ())’ + +tcfail157.hs:27:10: error: + Variable ‘b’ occurs more often + in the constraint ‘E m a b’ than in the instance head + (Use UndecidableInstances to permit this) + In the instance declaration for ‘Foo m (a -> ())’ + +tcfail157.hs:27:10: error: + Variable ‘b’ occurs more often + in the constraint ‘Foo m b’ than in the instance head + (Use UndecidableInstances to permit this) + In the instance declaration for ‘Foo m (a -> ())’ -- cgit v1.2.1