diff options
author | Simon Peyton Jones <simonpj@microsoft.com> | 2015-05-11 23:19:14 +0100 |
---|---|---|
committer | Simon Peyton Jones <simonpj@microsoft.com> | 2015-05-13 09:02:13 +0100 |
commit | 130e93aab220bdf14d08028771f83df210da340b (patch) | |
tree | 4bd4ca6cbccea45d6c977122bc375fa101ff199a /testsuite/tests/typecheck/should_fail/fd-loop.stderr | |
parent | 8da785d59f5989b9a9df06386d5bd13f65435bc0 (diff) | |
download | haskell-130e93aab220bdf14d08028771f83df210da340b.tar.gz |
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
Diffstat (limited to 'testsuite/tests/typecheck/should_fail/fd-loop.stderr')
-rw-r--r-- | testsuite/tests/typecheck/should_fail/fd-loop.stderr | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/testsuite/tests/typecheck/should_fail/fd-loop.stderr b/testsuite/tests/typecheck/should_fail/fd-loop.stderr index 96fbc3ef18..44a0618181 100644 --- a/testsuite/tests/typecheck/should_fail/fd-loop.stderr +++ b/testsuite/tests/typecheck/should_fail/fd-loop.stderr @@ -1,12 +1,12 @@ - -fd-loop.hs:12:10: - Variable ‘b’ occurs more often than in the instance head - in the constraint: C a b - (Use UndecidableInstances to permit this) - In the instance declaration for ‘Eq (T a)’ - -fd-loop.hs:12:10: - Variable ‘b’ occurs more often than in the instance head - in the constraint: Eq b - (Use UndecidableInstances to permit this) - In the instance declaration for ‘Eq (T a)’ +
+fd-loop.hs:12:10: error:
+ Variable ‘b’ occurs more often
+ in the constraint ‘C a b’ than in the instance head
+ (Use UndecidableInstances to permit this)
+ In the instance declaration for ‘Eq (T a)’
+
+fd-loop.hs:12:10: error:
+ Variable ‘b’ occurs more often
+ in the constraint ‘Eq b’ than in the instance head
+ (Use UndecidableInstances to permit this)
+ In the instance declaration for ‘Eq (T a)’
|