conflictInstErr famInst (head conflicts)
}
where
- -- * In the case of data family instances, any overlap is fundamentally a
+ -- - In the case of data family instances, any overlap is fundamentally a
-- conflict (as these instances imply injective type mappings).
- -- * In the case of type family instances, overlap is admitted as long as
+ -- - In the case of type family instances, overlap is admitted as long as
-- the right-hand sides of the overlapping rules coincide under the
-- overlap substitution. We require that they are syntactically equal;
-- anything else would be difficult to test for at this stage.
<+> ptext (sLit "is unified with another quantified type variable")
<+> quotes (ppr tidy_tv2)
; failWithTcM (env2, msg) }
- where
\end{code}
-- to use when generating a warning
mkArbitraryType warn tv
| liftedTypeKind `isSubKind` kind -- The vastly common case
- = return anyPrimTy
- | eqKind kind (tyConKind anyPrimTyCon1) -- *->*
+ = return anyPrimTy
+ | eqKind kind (tyConKind anyPrimTyCon1) -- @*->*@
= return (mkTyConApp anyPrimTyCon1 []) -- No tuples this size
- | all isLiftedTypeKind args -- *-> ... ->*->*
+ | all isLiftedTypeKind args -- @*-> ... ->*->*@
, isLiftedTypeKind res -- Horrible hack to make less use
= return (mkTyConApp tup_tc []) -- of mkAnyPrimTyCon
| otherwise
-- to the fields for that constructor
-- This is used when dealing with ".." notation in record
-- construction and pattern matching.
- -- The FieldEnv deals *only* with constructors defined in
- -- *thie* module. For imported modules, we get the same info
- -- from the TypeEnv
+ -- The FieldEnv deals *only* with constructors defined in *thie*
+ -- module. For imported modules, we get the same info from the
+ -- TypeEnv
\end{code}
%************************************************************************
Here is a more complicated example:
-| > class Foo a b | a->b
-| >
-| > class Bar a b | a->b
-| >
-| > data Obj = Obj
-| >
-| > instance Bar Obj Obj
-| >
-| > instance (Bar a b) => Foo a b
-| >
-| > foo:: (Foo a b) => a -> String
-| > foo _ = "works"
-| >
-| > runFoo:: (forall a b. (Foo a b) => a -> w) -> w
-| > runFoo f = f Obj
-|
-| *Test> runFoo foo
-|
-| <interactive>:1:
-| Could not deduce (Bar a b) from the context (Foo a b)
-| arising from use of `foo' at <interactive>:1
-| Probable fix:
-| Add (Bar a b) to the expected type of an expression
-| In the first argument of `runFoo', namely `foo'
-| In the definition of `it': it = runFoo foo
-|
-| Why all of the sudden does GHC need the constraint Bar a b? The
-| function foo didn't ask for that...
+@
+ > class Foo a b | a->b
+ >
+ > class Bar a b | a->b
+ >
+ > data Obj = Obj
+ >
+ > instance Bar Obj Obj
+ >
+ > instance (Bar a b) => Foo a b
+ >
+ > foo:: (Foo a b) => a -> String
+ > foo _ = "works"
+ >
+ > runFoo:: (forall a b. (Foo a b) => a -> w) -> w
+ > runFoo f = f Obj
+
+ *Test> runFoo foo
+
+ <interactive>:1:
+ Could not deduce (Bar a b) from the context (Foo a b)
+ arising from use of `foo' at <interactive>:1
+ Probable fix:
+ Add (Bar a b) to the expected type of an expression
+ In the first argument of `runFoo', namely `foo'
+ In the definition of `it': it = runFoo foo
+
+ Why all of the sudden does GHC need the constraint Bar a b? The
+ function foo didn't ask for that...
+@
The trouble is that to type (runFoo foo), GHC has to solve the problem:
; return init_state
}
- -- *** ToDo: what to do with the "extra_givens"? For the
+ -- !!! ToDo: what to do with the "extra_givens"? For the
-- moment I'm simply discarding them, which is probably wrong
-- 6. Solve the *wanted* *dictionary* constraints (not implications)
| otherwise = do
(_errs, mb_r) <- tryTc (unifyKind exp_kind act_kind)
case mb_r of
- Just _ -> return () ; -- Unification succeeded
+ Just _ -> return () -- Unification succeeded
Nothing -> do
-- So there's definitely an error