b9edd5f046a703728f251c9173492ac0015ed94b
[ghc-hetmet.git] / compiler / typecheck / TcCanonical.lhs
1 \begin{code}
2 module TcCanonical(
3     mkCanonical, mkCanonicals, canWanteds, canGivens, canOccursCheck, canEq,
4  ) where
5
6 #include "HsVersions.h"
7
8 import BasicTypes 
9 import Type
10 import TcRnTypes
11
12 import TcType
13 import TcErrors
14 import Coercion
15 import Class
16 import TyCon
17 import TypeRep
18 import Name
19 import Var
20 import Outputable
21 import Control.Monad    ( when, zipWithM )
22 import MonadUtils
23 import Control.Applicative ( (<|>) )
24
25 import VarSet
26 import Bag
27
28 import HsBinds 
29
30 import Control.Monad  ( unless )
31 import TcSMonad  -- The TcS Monad 
32 \end{code}
33
34 Note [Canonicalisation]
35 ~~~~~~~~~~~~~~~~~~~~~~~
36 * Converts (Constraint f) _which_does_not_contain_proper_implications_ to CanonicalCts
37 * Unary: treats individual constraints one at a time
38 * Does not do any zonking
39 * Lives in TcS monad so that it can create new skolem variables
40
41
42 %************************************************************************
43 %*                                                                      *
44 %*        Flattening (eliminating all function symbols)                 *
45 %*                                                                      *
46 %************************************************************************
47
48 Note [Flattening]
49 ~~~~~~~~~~~~~~~~~~~~
50   flatten ty  ==>   (xi, cc)
51     where
52       xi has no type functions
53       cc = Auxiliary given (equality) constraints constraining
54            the fresh type variables in xi.  Evidence for these 
55            is always the identity coercion, because internally the
56            fresh flattening skolem variables are actually identified
57            with the types they have been generated to stand in for.
58
59 Note that it is flatten's job to flatten *every type function it sees*.
60 flatten is only called on *arguments* to type functions, by canEqGiven.
61
62 Recall that in comments we use alpha[flat = ty] to represent a
63 flattening skolem variable alpha which has been generated to stand in
64 for ty.
65
66 ----- Example of flattening a constraint: ------
67   flatten (List (F (G Int)))  ==>  (xi, cc)
68     where
69       xi  = List alpha
70       cc  = { G Int ~ beta[flat = G Int],
71               F beta ~ alpha[flat = F beta] }
72 Here
73   * alpha and beta are 'flattening skolem variables'.
74   * All the constraints in cc are 'given', and all their coercion terms 
75     are the identity.
76
77 NB: Flattening Skolems only occur in canonical constraints, which
78 are never zonked, so we don't need to worry about zonking doing
79 accidental unflattening.
80
81 Note that we prefer to leave type synonyms unexpanded when possible,
82 so when the flattener encounters one, it first asks whether its
83 transitive expansion contains any type function applications.  If so,
84 it expands the synonym and proceeds; if not, it simply returns the
85 unexpanded synonym.
86
87 TODO: caching the information about whether transitive synonym
88 expansions contain any type function applications would speed things
89 up a bit; right now we waste a lot of energy traversing the same types
90 multiple times.
91
92 \begin{code}
93 -- Flatten a bunch of types all at once.
94 flattenMany :: CtFlavor -> [Type] -> TcS ([Xi], [Coercion], CanonicalCts)
95 -- Coercions :: Xi ~ Type 
96 flattenMany ctxt tys 
97   = do { (xis, cos, cts_s) <- mapAndUnzip3M (flatten ctxt) tys
98        ; return (xis, cos, andCCans cts_s) }
99
100 -- Flatten a type to get rid of type function applications, returning
101 -- the new type-function-free type, and a collection of new equality
102 -- constraints.  See Note [Flattening] for more detail.
103 flatten :: CtFlavor -> TcType -> TcS (Xi, Coercion, CanonicalCts)
104 -- Postcondition: Coercion :: Xi ~ TcType 
105 flatten ctxt ty 
106   | Just ty' <- tcView ty
107   = do { (xi, co, ccs) <- flatten ctxt ty'
108         -- Preserve type synonyms if possible
109         -- We can tell if ty' is function-free by
110         -- whether there are any floated constraints
111        ; if isEmptyCCan ccs then
112              return (ty, ty, emptyCCan)  
113          else
114              return (xi, co, ccs) }
115
116 flatten _ v@(TyVarTy _)
117   = return (v, v, emptyCCan)
118
119 flatten ctxt (AppTy ty1 ty2)
120   = do { (xi1,co1,c1) <- flatten ctxt ty1
121        ; (xi2,co2,c2) <- flatten ctxt ty2
122        ; return (mkAppTy xi1 xi2, mkAppCoercion co1 co2, c1 `andCCan` c2) }
123
124 flatten ctxt (FunTy ty1 ty2)
125   = do { (xi1,co1,c1) <- flatten ctxt ty1
126        ; (xi2,co2,c2) <- flatten ctxt ty2
127        ; return (mkFunTy xi1 xi2, mkFunCoercion co1 co2, c1 `andCCan` c2) }
128
129 flatten fl (TyConApp tc tys)
130   -- For a normal type constructor or data family application, we just
131   -- recursively flatten the arguments.
132   | not (isSynFamilyTyCon tc)
133     = do { (xis,cos,ccs) <- flattenMany fl tys
134          ; return (mkTyConApp tc xis, mkTyConCoercion tc cos, ccs) }
135
136   -- Otherwise, it's a type function application, and we have to
137   -- flatten it away as well, and generate a new given equality constraint
138   -- between the application and a newly generated flattening skolem variable.
139   | otherwise 
140   = ASSERT( tyConArity tc <= length tys )       -- Type functions are saturated
141       do { (xis, cos, ccs) <- flattenMany fl tys
142          ; let (xi_args, xi_rest)  = splitAt (tyConArity tc) xis
143                (cos_args, cos_rest) = splitAt (tyConArity tc) cos 
144                  -- The type function might be *over* saturated
145                  -- in which case the remaining arguments should
146                  -- be dealt with by AppTys
147                fam_ty = mkTyConApp tc xi_args 
148                fam_co = fam_ty -- identity 
149
150          ; (ret_co, rhs_var, ct) <- 
151              if isGiven fl then
152                do { rhs_var <- newFlattenSkolemTy fam_ty
153                   ; cv <- newGivOrDerCoVar fam_ty rhs_var fam_co
154                   ; let ct = CFunEqCan { cc_id     = cv
155                                        , cc_flavor = fl -- Given
156                                        , cc_fun    = tc 
157                                        , cc_tyargs = xi_args 
158                                        , cc_rhs    = rhs_var }
159                   ; return $ (mkCoVarCoercion cv, rhs_var, ct) }
160              else -- Derived or Wanted: make a new *unification* flatten variable
161                do { rhs_var <- newFlexiTcSTy (typeKind fam_ty)
162                   ; cv <- newWantedCoVar fam_ty rhs_var
163                   ; let ct = CFunEqCan { cc_id = cv
164                                        , cc_flavor = mkWantedFlavor fl
165                                            -- Always Wanted, not Derived
166                                        , cc_fun = tc
167                                        , cc_tyargs = xi_args
168                                        , cc_rhs    = rhs_var }
169                   ; return $ (mkCoVarCoercion cv, rhs_var, ct) }
170
171          ; return ( foldl AppTy rhs_var xi_rest
172                   , foldl AppTy (mkSymCoercion ret_co 
173                                     `mkTransCoercion` mkTyConCoercion tc cos_args) cos_rest
174                   , ccs `extendCCans` ct) }
175
176
177 flatten ctxt (PredTy pred) 
178   = do { (pred', co, ccs) <- flattenPred ctxt pred
179        ; return (PredTy pred', co, ccs) }
180
181 flatten ctxt ty@(ForAllTy {})
182 -- We allow for-alls when, but only when, no type function
183 -- applications inside the forall involve the bound type variables
184 -- TODO: What if it is a (t1 ~ t2) => t3
185 --       Must revisit when the New Coercion API is here! 
186   = do { let (tvs, rho) = splitForAllTys ty
187        ; (rho', co, ccs) <- flatten ctxt rho
188        ; let bad_eqs  = filterBag is_bad ccs
189              is_bad c = tyVarsOfCanonical c `intersectsVarSet` tv_set
190              tv_set   = mkVarSet tvs
191        ; unless (isEmptyBag bad_eqs)
192                 (flattenForAllErrorTcS ctxt ty bad_eqs)
193        ; return (mkForAllTys tvs rho', mkForAllTys tvs co, ccs)  }
194
195 ---------------
196 flattenPred :: CtFlavor -> TcPredType -> TcS (TcPredType, Coercion, CanonicalCts)
197 flattenPred ctxt (ClassP cls tys)
198   = do { (tys', cos, ccs) <- flattenMany ctxt tys
199        ; return (ClassP cls tys', mkClassPPredCo cls cos, ccs) }
200 flattenPred ctxt (IParam nm ty)
201   = do { (ty', co, ccs) <- flatten ctxt ty
202        ; return (IParam nm ty', mkIParamPredCo nm co, ccs) }
203 -- TODO: Handling of coercions between EqPreds must be revisited once the New Coercion API is ready!
204 flattenPred ctxt (EqPred ty1 ty2)
205   = do { (ty1', co1, ccs1) <- flatten ctxt ty1
206        ; (ty2', co2, ccs2) <- flatten ctxt ty2
207        ; return (EqPred ty1' ty2', mkEqPredCo co1 co2, ccs1 `andCCan` ccs2) }
208
209 \end{code}
210
211 %************************************************************************
212 %*                                                                      *
213 %*                Canonicalising given constraints                      *
214 %*                                                                      *
215 %************************************************************************
216
217 \begin{code}
218 canWanteds :: [WantedEvVar] -> TcS CanonicalCts 
219 canWanteds = fmap andCCans . mapM (\(WantedEvVar ev loc) -> mkCanonical (Wanted loc) ev)
220
221 canGivens :: GivenLoc -> [EvVar] -> TcS CanonicalCts
222 canGivens loc givens = do { ccs <- mapM (mkCanonical (Given loc)) givens
223                           ; return (andCCans ccs) }
224
225 mkCanonicals :: CtFlavor -> [EvVar] -> TcS CanonicalCts 
226 mkCanonicals fl vs = fmap andCCans (mapM (mkCanonical fl) vs)
227
228 mkCanonical :: CtFlavor -> EvVar -> TcS CanonicalCts 
229 mkCanonical fl ev = case evVarPred ev of 
230                         ClassP clas tys -> canClass fl ev clas tys 
231                         IParam ip ty    -> canIP    fl ev ip ty
232                         EqPred ty1 ty2  -> canEq    fl ev ty1 ty2 
233                          
234
235 canClass :: CtFlavor -> EvVar -> Class -> [TcType] -> TcS CanonicalCts 
236 canClass fl v cn tys 
237   = do { (xis,cos,ccs) <- flattenMany fl tys  -- cos :: xis ~ tys
238        ; let no_flattening_happened = isEmptyCCan ccs
239              dict_co = mkTyConCoercion (classTyCon cn) cos
240        ; v_new <- if no_flattening_happened then return v
241                   else if isGiven fl        then return v
242                          -- The cos are all identities if fl=Given,
243                          -- hence nothing to do
244                   else do { v' <- newDictVar cn xis  -- D xis
245                           ; if isWanted fl
246                             then setDictBind v  (EvCast v' dict_co)
247                             else setDictBind v' (EvCast v (mkSymCoercion dict_co))
248                           ; return v' }
249
250        -- Add the superclasses of this one here, See Note [Adding superclasses]
251        ; sc_cts <- newSCWorkFromFlavored v_new fl cn xis
252
253        ; return (sc_cts `andCCan` ccs `extendCCans` CDictCan { cc_id     = v_new
254                                                              , cc_flavor = fl
255                                                              , cc_class  = cn 
256                                                              , cc_tyargs = xis }) }
257
258 \end{code}
259
260 Note [Adding superclasses]
261 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 
262 Since dictionaries are canonicalized only once in their lifetime, the
263 place to add their superclasses is canonicalisation (The alternative
264 would be to do it during constraint solving, but we'd have to be
265 extremely careful to not repeatedly introduced the same superclass in
266 our worklist). Here is what we do:
267
268 For Givens: 
269        We add all their superclasses as Givens. 
270
271 For Wanteds: 
272        Generally speaking, we want to be able to add derived
273        superclasses of unsolved wanteds, and wanteds that have been
274        partially being solved via an instance. This is important to be
275        able to simplify the inferred constraints more (and to allow
276        for recursive dictionaries, less importantly).
277
278        Example: Inferred wanted constraint is (Eq a, Ord a), but we'd
279        only like to quantify over Ord a, hence we would like to be
280        able to add the superclass of Ord a as Derived and use it to
281        solve the wanted Eq a.
282
283 For Deriveds: 
284        Deriveds either arise as wanteds that have been partially
285        solved, or as superclasses of other wanteds or deriveds. Hence,
286        their superclasses must be already there so we must do nothing
287        at al.
288
289        DV: In fact, it is probably true that the canonicaliser is
290           *never* asked to canonicalise Derived dictionaries
291
292 There is one disadvantage to this. Suppose the wanted constraints are
293 (Num a, Num a).  Then we'll add all the superclasses of both during
294 canonicalisation, only to eliminate them later when they are
295 interacted.  That seems like a waste of work.  Still, it's simple.
296
297 Here's an example that demonstrates why we chose to NOT add
298 superclasses during simplification: [Comes from ticket #4497]
299
300    class Num (RealOf t) => Normed t
301    type family RealOf x
302
303 Assume the generated wanted constraint is: 
304    RealOf e ~ e, Normed e 
305 If we were to be adding the superclasses during simplification we'd get: 
306    Num uf, Normed e, RealOf e ~ e, RealOf e ~ uf 
307 ==> 
308    e ~ uf, Num uf, Normed e, RealOf e ~ e 
309 ==> [Spontaneous solve] 
310    Num uf, Normed uf, RealOf uf ~ uf 
311
312 While looks exactly like our original constraint. If we add the superclass again we'd loop. 
313 By adding superclasses definitely only once, during canonicalisation, this situation can't 
314 happen.
315
316 \begin{code}
317 newSCWorkFromFlavored :: EvVar -> CtFlavor -> Class -> [Xi] -> TcS CanonicalCts
318 -- Returns superclasses, see Note [Adding superclasses]
319 newSCWorkFromFlavored ev orig_flavor cls xis 
320   = do { let (tyvars, sc_theta, _, _) = classBigSig cls 
321              sc_theta1 = substTheta (zipTopTvSubst tyvars xis) sc_theta
322        ; sc_vars <- zipWithM inst_one sc_theta1 [0..]
323        ; mkCanonicals flavor sc_vars }
324              -- NB: Since there is a call to mkCanonicals,
325              -- this will add *recursively* all superclasses
326   where
327     inst_one pred n = newGivOrDerEvVar pred (EvSuperClass ev n)
328     flavor = case orig_flavor of 
329                Given loc  -> Given loc
330                Wanted loc -> Derived loc DerSC
331                Derived {} -> orig_flavor
332                    -- NB: the non-immediate superclasses will show up as
333                    --     Derived, and we want their superclasses too!
334
335 canIP :: CtFlavor -> EvVar -> IPName Name -> TcType -> TcS CanonicalCts
336 -- See Note [Canonical implicit parameter constraints] to see why we don't 
337 -- immediately canonicalize (flatten) IP constraints. 
338 canIP fl v nm ty 
339   = return $ singleCCan $ CIPCan { cc_id = v
340                                  , cc_flavor = fl
341                                  , cc_ip_nm = nm
342                                  , cc_ip_ty = ty } 
343
344 -----------------
345 canEq :: CtFlavor -> EvVar -> Type -> Type -> TcS CanonicalCts 
346 canEq fl cv ty1 ty2 
347   | tcEqType ty1 ty2    -- Dealing with equality here avoids
348                         -- later spurious occurs checks for a~a
349   = do { when (isWanted fl) (setWantedCoBind cv ty1)
350        ; return emptyCCan }
351
352 -- If one side is a variable, orient and flatten, 
353 -- WITHOUT expanding type synonyms, so that we tend to 
354 -- substitute a ~ Age rather than a ~ Int when @type Age = Int@
355 canEq fl cv ty1@(TyVarTy {}) ty2 
356   = do { untch <- getUntouchables 
357        ; canEqLeaf untch fl cv (classify ty1) (classify ty2) }
358 canEq fl cv ty1 ty2@(TyVarTy {}) 
359   = do { untch <- getUntouchables 
360        ; canEqLeaf untch fl cv (classify ty1) (classify ty2) }
361       -- NB: don't use VarCls directly because tv1 or tv2 may be scolems!
362
363 canEq fl cv (TyConApp fn tys) ty2 
364   | isSynFamilyTyCon fn, length tys == tyConArity fn
365   = do { untch <- getUntouchables 
366        ; canEqLeaf untch fl cv (FunCls fn tys) (classify ty2) }
367 canEq fl cv ty1 (TyConApp fn tys)
368   | isSynFamilyTyCon fn, length tys == tyConArity fn
369   = do { untch <- getUntouchables 
370        ; canEqLeaf untch fl cv (classify ty1) (FunCls fn tys) }
371
372 canEq fl cv s1 s2
373   | Just (t1a,t1b,t1c) <- splitCoPredTy_maybe s1, 
374     Just (t2a,t2b,t2c) <- splitCoPredTy_maybe s2
375   = do { (v1,v2,v3) <- if isWanted fl then 
376                          do { v1 <- newWantedCoVar t1a t2a
377                             ; v2 <- newWantedCoVar t1b t2b 
378                             ; v3 <- newWantedCoVar t1c t2c 
379                             ; let res_co = mkCoPredCo (mkCoVarCoercion v1) 
380                                                       (mkCoVarCoercion v2) (mkCoVarCoercion v3)
381                             ; setWantedCoBind cv res_co
382                             ; return (v1,v2,v3) }
383                        else let co_orig = mkCoVarCoercion cv 
384                                 coa = mkCsel1Coercion co_orig
385                                 cob = mkCsel2Coercion co_orig
386                                 coc = mkCselRCoercion co_orig
387                             in do { v1 <- newGivOrDerCoVar t1a t2a coa
388                                   ; v2 <- newGivOrDerCoVar t1b t2b cob
389                                   ; v3 <- newGivOrDerCoVar t1c t2c coc 
390                                   ; return (v1,v2,v3) }
391        ; cc1 <- canEq fl v1 t1a t2a 
392        ; cc2 <- canEq fl v2 t1b t2b 
393        ; cc3 <- canEq fl v3 t1c t2c 
394        ; return (cc1 `andCCan` cc2 `andCCan` cc3) }
395
396
397 -- Split up an equality between function types into two equalities.
398 canEq fl cv (FunTy s1 t1) (FunTy s2 t2)
399   = do { (argv, resv) <- 
400              if isWanted fl then 
401                  do { argv <- newWantedCoVar s1 s2 
402                     ; resv <- newWantedCoVar t1 t2 
403                     ; setWantedCoBind cv $ 
404                       mkFunCoercion (mkCoVarCoercion argv) (mkCoVarCoercion resv) 
405                     ; return (argv,resv) } 
406              else let [arg,res] = decomposeCo 2 (mkCoVarCoercion cv) 
407                   in do { argv <- newGivOrDerCoVar s1 s2 arg 
408                         ; resv <- newGivOrDerCoVar t1 t2 res
409                         ; return (argv,resv) } 
410        ; cc1 <- canEq fl argv s1 s2 -- inherit original kinds and locations
411        ; cc2 <- canEq fl resv t1 t2
412        ; return (cc1 `andCCan` cc2) }
413
414 canEq fl cv (PredTy (IParam n1 t1)) (PredTy (IParam n2 t2))
415   | n1 == n2
416   = if isWanted fl then 
417         do { v <- newWantedCoVar t1 t2 
418            ; setWantedCoBind cv $ mkIParamPredCo n1 (mkCoVarCoercion cv)
419            ; canEq fl v t1 t2 } 
420     else return emptyCCan -- DV: How to decompose given IP coercions? 
421
422 canEq fl cv (PredTy (ClassP c1 tys1)) (PredTy (ClassP c2 tys2))
423   | c1 == c2
424   = if isWanted fl then 
425        do { vs <- zipWithM newWantedCoVar tys1 tys2 
426           ; setWantedCoBind cv $ mkClassPPredCo c1 (map mkCoVarCoercion vs) 
427           ; andCCans <$> zipWith3M (canEq fl) vs tys1 tys2
428           }
429     else return emptyCCan 
430   -- How to decompose given dictionary (and implicit parameter) coercions? 
431   -- You may think that the following is right: 
432   --    let cos = decomposeCo (length tys1) (mkCoVarCoercion cv) 
433   --    in  zipWith3M newGivOrDerCoVar tys1 tys2 cos
434   -- But this assumes that the coercion is a type constructor-based 
435   -- coercion, and not a PredTy (ClassP cn cos) coercion. So we chose
436   -- to not decompose these coercions. We have to get back to this 
437   -- when we clean up the Coercion API.
438
439 canEq fl cv (TyConApp tc1 tys1) (TyConApp tc2 tys2)
440   | isAlgTyCon tc1 && isAlgTyCon tc2
441   , tc1 == tc2
442   , length tys1 == length tys2
443   = -- Generate equalities for each of the corresponding arguments
444     do { argsv <- if isWanted fl then
445                     do { argsv <- zipWithM newWantedCoVar tys1 tys2
446                             ; setWantedCoBind cv $ mkTyConCoercion tc1 (map mkCoVarCoercion argsv)
447                             ; return argsv } 
448                   else 
449                     let cos = decomposeCo (length tys1) (mkCoVarCoercion cv) 
450                     in zipWith3M newGivOrDerCoVar tys1 tys2 cos
451        ; andCCans <$> zipWith3M (canEq fl) argsv tys1 tys2 }
452
453 -- See Note [Equality between type applications]
454 --     Note [Care with type applications] in TcUnify
455 canEq fl cv ty1 ty2
456   | Just (s1,t1) <- tcSplitAppTy_maybe ty1
457   , Just (s2,t2) <- tcSplitAppTy_maybe ty2
458     = do { (cv1,cv2) <- 
459              if isWanted fl 
460              then do { cv1 <- newWantedCoVar s1 s2 
461                      ; cv2 <- newWantedCoVar t1 t2 
462                      ; setWantedCoBind cv $ 
463                        mkAppCoercion (mkCoVarCoercion cv1) (mkCoVarCoercion cv2) 
464                      ; return (cv1,cv2) } 
465              else let co1 = mkLeftCoercion  $ mkCoVarCoercion cv 
466                       co2 = mkRightCoercion $ mkCoVarCoercion cv
467                   in do { cv1 <- newGivOrDerCoVar s1 s2 co1 
468                         ; cv2 <- newGivOrDerCoVar t1 t2 co2 
469                         ; return (cv1,cv2) } 
470          ; cc1 <- canEq fl cv1 s1 s2 
471          ; cc2 <- canEq fl cv2 t1 t2 
472          ; return (cc1 `andCCan` cc2) } 
473
474 canEq fl _ s1@(ForAllTy {}) s2@(ForAllTy {})  
475  | tcIsForAllTy s1, tcIsForAllTy s2, 
476    Wanted {} <- fl 
477  = canEqFailure fl s1 s2
478  | otherwise
479  = do { traceTcS "Ommitting decomposition of given polytype equality" (pprEq s1 s2)
480       ; return emptyCCan }
481
482 -- Finally expand any type synonym applications.
483 canEq fl cv ty1 ty2 | Just ty1' <- tcView ty1 = canEq fl cv ty1' ty2
484 canEq fl cv ty1 ty2 | Just ty2' <- tcView ty2 = canEq fl cv ty1 ty2'
485 canEq fl _  ty1 ty2                           = canEqFailure fl ty1 ty2
486
487 canEqFailure :: CtFlavor -> Type -> Type -> TcS CanonicalCts
488 canEqFailure fl ty1 ty2
489   = do { addErrorTcS MisMatchError fl ty1 ty2
490        ; return emptyCCan }
491 \end{code}
492
493 Note [Equality between type applications]
494 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
495 If we see an equality of the form s1 t1 ~ s2 t2 we can always split
496 it up into s1 ~ s2 /\ t1 ~ t2, since s1 and s2 can't be type
497 functions (type functions use the TyConApp constructor, which never
498 shows up as the LHS of an AppTy).  Other than type functions, types
499 in Haskell are always 
500
501   (1) generative: a b ~ c d implies a ~ c, since different type
502       constructors always generate distinct types
503
504   (2) injective: a b ~ a d implies b ~ d; we never generate the
505       same type from different type arguments.
506
507
508 Note [Canonical ordering for equality constraints]
509 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
510 Implemented as (<+=) below:
511
512   - Type function applications always come before anything else.  
513   - Variables always come before non-variables (other than type
514       function applications).
515
516 Note that we don't need to unfold type synonyms on the RHS to check
517 the ordering; that is, in the rules above it's OK to consider only
518 whether something is *syntactically* a type function application or
519 not.  To illustrate why this is OK, suppose we have an equality of the
520 form 'tv ~ S a b c', where S is a type synonym which expands to a
521 top-level application of the type function F, something like
522
523   type S a b c = F d e
524
525 Then to canonicalize 'tv ~ S a b c' we flatten the RHS, and since S's
526 expansion contains type function applications the flattener will do
527 the expansion and then generate a skolem variable for the type
528 function application, so we end up with something like this:
529
530   tv ~ x
531   F d e ~ x
532
533 where x is the skolem variable.  This is one extra equation than
534 absolutely necessary (we could have gotten away with just 'F d e ~ tv'
535 if we had noticed that S expanded to a top-level type function
536 application and flipped it around in the first place) but this way
537 keeps the code simpler.
538
539 Unlike the OutsideIn(X) draft of May 7, 2010, we do not care about the
540 ordering of tv ~ tv constraints.  There are several reasons why we
541 might:
542
543   (1) In order to be able to extract a substitution that doesn't
544       mention untouchable variables after we are done solving, we might
545       prefer to put touchable variables on the left. However, in and
546       of itself this isn't necessary; we can always re-orient equality
547       constraints at the end if necessary when extracting a substitution.
548
549   (2) To ensure termination we might think it necessary to put
550       variables in lexicographic order. However, this isn't actually 
551       necessary as outlined below.
552
553 While building up an inert set of canonical constraints, we maintain
554 the invariant that the equality constraints in the inert set form an
555 acyclic rewrite system when viewed as L-R rewrite rules.  Moreover,
556 the given constraints form an idempotent substitution (i.e. none of
557 the variables on the LHS occur in any of the RHS's, and type functions
558 never show up in the RHS at all), the wanted constraints also form an
559 idempotent substitution, and finally the LHS of a given constraint
560 never shows up on the RHS of a wanted constraint.  There may, however,
561 be a wanted LHS that shows up in a given RHS, since we do not rewrite
562 given constraints with wanted constraints.
563
564 Suppose we have an inert constraint set
565
566
567   tg_1 ~ xig_1         -- givens
568   tg_2 ~ xig_2
569   ...
570   tw_1 ~ xiw_1         -- wanteds
571   tw_2 ~ xiw_2
572   ...
573
574 where each t_i can be either a type variable or a type function
575 application. Now suppose we take a new canonical equality constraint,
576 t' ~ xi' (note among other things this means t' does not occur in xi')
577 and try to react it with the existing inert set.  We show by induction
578 on the number of t_i which occur in t' ~ xi' that this process will
579 terminate.
580
581 There are several ways t' ~ xi' could react with an existing constraint:
582
583 TODO: finish this proof.  The below was for the case where the entire
584 inert set is an idempotent subustitution...
585
586 (b) We could have t' = t_j for some j.  Then we obtain the new
587     equality xi_j ~ xi'; note that neither xi_j or xi' contain t_j.  We
588     now canonicalize the new equality, which may involve decomposing it
589     into several canonical equalities, and recurse on these.  However,
590     none of the new equalities will contain t_j, so they have fewer
591     occurrences of the t_i than the original equation.
592
593 (a) We could have t_j occurring in xi' for some j, with t' /=
594     t_j. Then we substitute xi_j for t_j in xi' and continue.  However,
595     since none of the t_i occur in xi_j, we have decreased the
596     number of t_i that occur in xi', since we eliminated t_j and did not
597     introduce any new ones.
598
599 \begin{code}
600 data TypeClassifier 
601   = FskCls TcTyVar      -- ^ Flatten skolem 
602   | VarCls TcTyVar      -- ^ Non-flatten-skolem variable 
603   | FunCls TyCon [Type] -- ^ Type function, exactly saturated
604   | OtherCls TcType     -- ^ Neither of the above
605
606 unClassify :: TypeClassifier -> TcType
607 unClassify (VarCls tv)      = TyVarTy tv
608 unClassify (FskCls tv) = TyVarTy tv 
609 unClassify (FunCls fn tys)  = TyConApp fn tys
610 unClassify (OtherCls ty)    = ty
611
612 classify :: TcType -> TypeClassifier
613
614 classify (TyVarTy tv) 
615   | isTcTyVar tv, 
616     FlatSkol {} <- tcTyVarDetails tv = FskCls tv
617   | otherwise                        = VarCls tv
618 classify (TyConApp tc tys) | isSynFamilyTyCon tc
619                            , tyConArity tc == length tys
620                            = FunCls tc tys
621 classify ty                | Just ty' <- tcView ty
622                            = case classify ty' of
623                                OtherCls {} -> OtherCls ty
624                                var_or_fn   -> var_or_fn
625                            | otherwise 
626                            = OtherCls ty
627
628 -- See note [Canonical ordering for equality constraints].
629 reOrient :: TcsUntouchables -> TypeClassifier -> TypeClassifier -> Bool 
630 -- (t1 `reOrient` t2) responds True 
631 --   iff we should flip to (t2~t1)
632 -- We try to say False if possible, to minimise evidence generation
633 --
634 -- Postcondition: After re-orienting, first arg is not OTherCls
635 reOrient _untch (OtherCls {}) (FunCls {})   = True
636 reOrient _untch (OtherCls {}) (FskCls {})   = True
637 reOrient _untch (OtherCls {}) (VarCls {})   = True
638 reOrient _untch (OtherCls {}) (OtherCls {}) = panic "reOrient"  -- One must be Var/Fun
639
640 reOrient _untch (FunCls {})   (VarCls {})    = False
641   -- See Note [No touchables as FunEq RHS] in TcSMonad
642 reOrient _untch (FunCls {}) _                = False             -- Fun/Other on rhs
643
644 reOrient _untch (VarCls {}) (FunCls {})      = True 
645
646 reOrient _untch (VarCls {}) (FskCls {})      = False
647
648 reOrient _untch (VarCls {})  (OtherCls {})   = False
649 reOrient _untch (VarCls tv1)  (VarCls tv2)  
650   | isMetaTyVar tv2 && not (isMetaTyVar tv1) = True 
651   | otherwise                                = False 
652   -- Just for efficiency, see CTyEqCan invariants 
653
654 reOrient _untch (FskCls {}) (VarCls tv2)     = isMetaTyVar tv2 
655   -- Just for efficiency, see CTyEqCan invariants
656
657 reOrient _untch (FskCls {}) (FskCls {})     = False
658 reOrient _untch (FskCls {}) (FunCls {})     = True 
659 reOrient _untch (FskCls {}) (OtherCls {})   = False 
660
661 ------------------
662 canEqLeaf :: TcsUntouchables 
663           -> CtFlavor -> CoVar 
664           -> TypeClassifier -> TypeClassifier -> TcS CanonicalCts 
665 -- Canonicalizing "leaf" equality constraints which cannot be
666 -- decomposed further (ie one of the types is a variable or
667 -- saturated type function application).  
668
669   -- Preconditions: 
670   --    * one of the two arguments is not OtherCls
671   --    * the two types are not equal (looking through synonyms)
672 canEqLeaf untch fl cv cls1 cls2 
673   | cls1 `re_orient` cls2
674   = do { cv' <- if isWanted fl 
675                 then do { cv' <- newWantedCoVar s2 s1 
676                         ; setWantedCoBind cv $ mkSymCoercion (mkCoVarCoercion cv') 
677                         ; return cv' } 
678                 else newGivOrDerCoVar s2 s1 (mkSymCoercion (mkCoVarCoercion cv)) 
679        ; canEqLeafOriented fl cv' cls2 s1 }
680
681   | otherwise
682   = canEqLeafOriented fl cv cls1 s2
683   where
684     re_orient = reOrient untch 
685     s1 = unClassify cls1  
686     s2 = unClassify cls2  
687
688 ------------------
689 canEqLeafOriented :: CtFlavor -> CoVar 
690                   -> TypeClassifier -> TcType -> TcS CanonicalCts 
691 -- First argument is not OtherCls
692 canEqLeafOriented fl cv cls1@(FunCls fn tys1) s2         -- cv : F tys1
693   | let k1 = kindAppResult (tyConKind fn) tys1,
694     let k2 = typeKind s2, 
695     isGiven fl && not (k1 `compatKind` k2) -- Establish the kind invariant for CFunEqCan
696   = addErrorTcS KindError fl (unClassify cls1) s2 >> return emptyCCan
697     -- Eagerly fails, see Note [Kind errors] in TcInteract
698
699   | otherwise 
700   = ASSERT2( isSynFamilyTyCon fn, ppr (unClassify cls1) )
701     do { (xis1,cos1,ccs1) <- flattenMany fl tys1 -- Flatten type function arguments
702                                                  -- cos1 :: xis1 ~ tys1
703        ; (xi2, co2, ccs2) <- flatten fl s2       -- Flatten entire RHS
704                                                  -- co2  :: xi2 ~ s2
705        ; let ccs = ccs1 `andCCan` ccs2
706              no_flattening_happened = isEmptyCCan ccs
707        ; cv_new <- if no_flattening_happened then return cv
708                    else if isGiven fl        then return cv
709                    else do { cv' <- newWantedCoVar (unClassify (FunCls fn xis1)) xi2
710                                  -- cv' : F xis ~ xi2
711                            ; let -- fun_co :: F xis1 ~ F tys1
712                                  fun_co = mkTyConCoercion fn cos1
713                                  -- want_co :: F tys1 ~ s2
714                                  want_co = mkSymCoercion fun_co
715                                            `mkTransCoercion` mkCoVarCoercion cv'
716                                            `mkTransCoercion` co2
717                                  -- der_co :: F xis1 ~ xi2
718                                  der_co = fun_co
719                                           `mkTransCoercion` mkCoVarCoercion cv
720                                           `mkTransCoercion` mkSymCoercion co2
721                            ; if isWanted fl
722                              then setWantedCoBind cv  want_co
723                              else setWantedCoBind cv' der_co
724                            ; return cv' }
725
726        ; let final_cc = CFunEqCan { cc_id     = cv_new
727                                   , cc_flavor = fl
728                                   , cc_fun    = fn
729                                   , cc_tyargs = xis1 
730                                   , cc_rhs    = xi2 }
731        ; return $ ccs `extendCCans` final_cc }
732
733 -- Otherwise, we have a variable on the left, so call canEqLeafTyVarLeft
734 canEqLeafOriented fl cv (FskCls tv) s2 
735   = canEqLeafTyVarLeft fl cv tv s2 
736 canEqLeafOriented fl cv (VarCls tv) s2 
737   = canEqLeafTyVarLeft fl cv tv s2 
738 canEqLeafOriented _ cv (OtherCls ty1) ty2 
739   = pprPanic "canEqLeaf" (ppr cv $$ ppr ty1 $$ ppr ty2)
740
741 canEqLeafTyVarLeft :: CtFlavor -> CoVar -> TcTyVar -> TcType -> TcS CanonicalCts
742 -- Establish invariants of CTyEqCans 
743 canEqLeafTyVarLeft fl cv tv s2       -- cv : tv ~ s2
744   | isGiven fl && not (k1 `compatKind` k2) -- Establish the kind invariant for CTyEqCan
745   = addErrorTcS KindError fl (mkTyVarTy tv) s2 >> return emptyCCan
746        -- Eagerly fails, see Note [Kind errors] in TcInteract
747   | otherwise
748   = do { (xi2, co, ccs2) <- flatten fl s2  -- Flatten RHS   co : xi2 ~ s2
749        ; mxi2' <- canOccursCheck fl tv xi2 -- Do an occurs check, and return a possibly
750                                            -- unfolded version of the RHS, if we had to 
751                                            -- unfold any type synonyms to get rid of tv.
752        ; case mxi2' of {
753            Nothing   -> addErrorTcS OccCheckError fl (mkTyVarTy tv) xi2 >> return emptyCCan ;
754            Just xi2' ->
755     do { let no_flattening_happened = isEmptyCCan ccs2
756        ; cv_new <- if no_flattening_happened then return cv
757                    else if isGiven fl        then return cv
758                    else do { cv' <- newWantedCoVar (mkTyVarTy tv) xi2'  -- cv' : tv ~ xi2
759                            ; if isWanted fl
760                              then setWantedCoBind cv  (mkCoVarCoercion cv' `mkTransCoercion` co)
761                              else setWantedCoBind cv' (mkCoVarCoercion cv  `mkTransCoercion`
762                                                        mkSymCoercion co)
763                            ; return cv' }
764
765        ; return $ ccs2 `extendCCans` CTyEqCan { cc_id     = cv_new
766                                               , cc_flavor = fl
767                                               , cc_tyvar  = tv
768                                               , cc_rhs    = xi2' } } } }
769   where
770     k1 = tyVarKind tv
771     k2 = typeKind s2
772
773 -- See Note [Type synonyms and canonicalization].
774 -- Check whether the given variable occurs in the given type.  We may
775 -- have needed to do some type synonym unfolding in order to get rid
776 -- of the variable, so we also return the unfolded version of the
777 -- type, which is guaranteed to be syntactically free of the given
778 -- type variable.  If the type is already syntactically free of the
779 -- variable, then the same type is returned.
780 --
781 -- Precondition: the two types are not equal (looking though synonyms)
782 canOccursCheck :: CtFlavor -> TcTyVar -> Xi -> TcS (Maybe Xi)
783 canOccursCheck _gw tv xi = return (expandAway tv xi)
784 \end{code}
785
786 @expandAway tv xi@ expands synonyms in xi just enough to get rid of
787 occurrences of tv, if that is possible; otherwise, it returns Nothing.
788 For example, suppose we have
789   type F a b = [a]
790 Then
791   expandAway b (F Int b) = Just [Int]
792 but
793   expandAway a (F a Int) = Nothing
794
795 We don't promise to do the absolute minimum amount of expanding
796 necessary, but we try not to do expansions we don't need to.  We
797 prefer doing inner expansions first.  For example,
798   type F a b = (a, Int, a, [a])
799   type G b   = Char
800 We have
801   expandAway b (F (G b)) = F Char
802 even though we could also expand F to get rid of b.
803
804 \begin{code}
805 expandAway :: TcTyVar -> Xi -> Maybe Xi
806 expandAway tv t@(TyVarTy tv') 
807   | tv == tv' = Nothing
808   | otherwise = Just t
809 expandAway tv xi
810   | not (tv `elemVarSet` tyVarsOfType xi) = Just xi
811 expandAway tv (AppTy ty1 ty2) 
812   = do { ty1' <- expandAway tv ty1
813        ; ty2' <- expandAway tv ty2 
814        ; return (mkAppTy ty1' ty2') }
815 -- mkAppTy <$> expandAway tv ty1 <*> expandAway tv ty2
816 expandAway tv (FunTy ty1 ty2)
817   = do { ty1' <- expandAway tv ty1 
818        ; ty2' <- expandAway tv ty2 
819        ; return (mkFunTy ty1' ty2') } 
820 -- mkFunTy <$> expandAway tv ty1 <*> expandAway tv ty2
821 expandAway tv ty@(ForAllTy {}) 
822   = let (tvs,rho) = splitForAllTys ty
823         tvs_knds  = map tyVarKind tvs 
824     in if tv `elemVarSet` tyVarsOfTypes tvs_knds then 
825        -- Can't expand away the kinds unless we create 
826        -- fresh variables which we don't want to do at this point.
827            Nothing 
828        else do { rho' <- expandAway tv rho
829                ; return (mkForAllTys tvs rho') }
830 expandAway tv (PredTy pred) 
831   = do { pred' <- expandAwayPred tv pred  
832        ; return (PredTy pred') }
833 -- For a type constructor application, first try expanding away the
834 -- offending variable from the arguments.  If that doesn't work, next
835 -- see if the type constructor is a type synonym, and if so, expand
836 -- it and try again.
837 expandAway tv ty@(TyConApp tc tys)
838   = (mkTyConApp tc <$> mapM (expandAway tv) tys) <|> (tcView ty >>= expandAway tv)
839
840 expandAwayPred :: TcTyVar -> TcPredType -> Maybe TcPredType 
841 expandAwayPred tv (ClassP cls tys) 
842   = do { tys' <- mapM (expandAway tv) tys; return (ClassP cls tys') } 
843 expandAwayPred tv (EqPred ty1 ty2)
844   = do { ty1' <- expandAway tv ty1
845        ; ty2' <- expandAway tv ty2 
846        ; return (EqPred ty1' ty2') }
847 expandAwayPred tv (IParam nm ty) 
848   = do { ty' <- expandAway tv ty
849        ; return (IParam nm ty') }
850
851                 
852
853 \end{code}
854
855 Note [Type synonyms and canonicalization]
856 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
857
858 We treat type synonym applications as xi types, that is, they do not
859 count as type function applications.  However, we do need to be a bit
860 careful with type synonyms: like type functions they may not be
861 generative or injective.  However, unlike type functions, they are
862 parametric, so there is no problem in expanding them whenever we see
863 them, since we do not need to know anything about their arguments in
864 order to expand them; this is what justifies not having to treat them
865 as specially as type function applications.  The thing that causes
866 some subtleties is that we prefer to leave type synonym applications
867 *unexpanded* whenever possible, in order to generate better error
868 messages.
869
870 If we encounter an equality constraint with type synonym applications
871 on both sides, or a type synonym application on one side and some sort
872 of type application on the other, we simply must expand out the type
873 synonyms in order to continue decomposing the equality constraint into
874 primitive equality constraints.  For example, suppose we have
875
876   type F a = [Int]
877
878 and we encounter the equality
879
880   F a ~ [b]
881
882 In order to continue we must expand F a into [Int], giving us the
883 equality
884
885   [Int] ~ [b]
886
887 which we can then decompose into the more primitive equality
888 constraint
889
890   Int ~ b.
891
892 However, if we encounter an equality constraint with a type synonym
893 application on one side and a variable on the other side, we should
894 NOT (necessarily) expand the type synonym, since for the purpose of
895 good error messages we want to leave type synonyms unexpanded as much
896 as possible.
897
898 However, there is a subtle point with type synonyms and the occurs
899 check that takes place for equality constraints of the form tv ~ xi.
900 As an example, suppose we have
901
902   type F a = Int
903
904 and we come across the equality constraint
905
906   a ~ F a
907
908 This should not actually fail the occurs check, since expanding out
909 the type synonym results in the legitimate equality constraint a ~
910 Int.  We must actually do this expansion, because unifying a with F a
911 will lead the type checker into infinite loops later.  Put another
912 way, canonical equality constraints should never *syntactically*
913 contain the LHS variable in the RHS type.  However, we don't always
914 need to expand type synonyms when doing an occurs check; for example,
915 the constraint
916
917   a ~ F b
918
919 is obviously fine no matter what F expands to. And in this case we
920 would rather unify a with F b (rather than F b's expansion) in order
921 to get better error messages later.
922
923 So, when doing an occurs check with a type synonym application on the
924 RHS, we use some heuristics to find an expansion of the RHS which does
925 not contain the variable from the LHS.  In particular, given
926
927   a ~ F t1 ... tn
928
929 we first try expanding each of the ti to types which no longer contain
930 a.  If this turns out to be impossible, we next try expanding F
931 itself, and so on.
932
933
934