From ffc21506894c7887d3620423aaf86bc6113a1071 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 - Haddock needs to absorb the change too; so there is a submodule update --- compiler/deSugar/DsCCall.hs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'compiler/deSugar/DsCCall.hs') diff --git a/compiler/deSugar/DsCCall.hs b/compiler/deSugar/DsCCall.hs index 5c5fde0b14..90121a0f5f 100644 --- a/compiler/deSugar/DsCCall.hs +++ b/compiler/deSugar/DsCCall.hs @@ -226,7 +226,7 @@ boxResult result_ty _ -> [] return_result state anss - = mkCoreConApps (tupleCon UnboxedTuple (2 + length extra_result_tys)) + = mkCoreConApps (tupleDataCon Unboxed (2 + length extra_result_tys)) (map Type (realWorldStatePrimTy : io_res_ty : extra_result_tys) ++ (state : anss)) @@ -290,9 +290,9 @@ mk_alt return_result (Just prim_res_ty, wrap_result) let the_rhs = return_result (Var state_id) (wrap_result (Var result_id) : map Var as) - ccall_res_ty = mkTyConApp (tupleTyCon UnboxedTuple arity) + ccall_res_ty = mkTyConApp (tupleTyCon Unboxed arity) (realWorldStatePrimTy : ls) - the_alt = ( DataAlt (tupleCon UnboxedTuple arity) + the_alt = ( DataAlt (tupleDataCon Unboxed arity) , (state_id : args_ids) , the_rhs ) -- cgit v1.2.1