author Simon Peyton Jones Sun, 23 Sep 2018 14:23:09 +0000 (15:23 +0100) committer Simon Peyton Jones Wed, 26 Sep 2018 03:36:28 +0000 (04:36 +0100)

index db29f67..3e50569 100644 (file)
@@ -2215,6 +2215,31 @@ For an example, see Trac #9211.
See also TcUnify Note [Deeper level on the left] for how we ensure
that the right variable is on the left of the equality when both are
tyvars.
+
+You might wonder whether the skokem really needs to be bound "in the
+very same implication" as the equuality constraint.
+(c.f. Trac #15009) Consider this:
+
+  data S a where
+    MkS :: (a ~ Int) => S a
+
+  g :: forall a. S a -> a -> blah
+  g x y = let h = \z. ( z :: Int
+                      , case x of
+                           MkS -> [y,z])
+          in ...
+
+From the type signature for `g`, we get `y::a` .  Then when when we
+encounter the `\z`, we'll assign `z :: alpha`, say.  Next, from the
+body of the lambda we'll get
+
+  [W] alpha ~ Int                             -- From z::Int
+  [W] forall. (a ~ Int) => [W] alpha ~ a   -- From [y,z]
+
+Now, suppose we decide to float `alpha ~ a` out of the implication
+and then unify `alpha := a`.  Now we are stuck!  But if treat
+`alpha ~ Int` first, and unify `alpha := Int`, all is fine.
+But we absolutely cannot float that equality or we will get stuck.
-}

removeInertCts :: [Ct] -> InertCans -> InertCans