simonpj 2006/01/05 05:10:55 PST
Modified files:
ghc/compiler/typecheck TcExpr.lhs
Log:
MERGE TO STABLE
This commit fixes a nasty problem discovered by Volker Stolz.
The problem is described in Note [Multiple instantiation] in
TcExpr, which is reproduced below.
(Core Lint identifies the problem, incidentally.)
tc200 is a test case.
Note [Multiple instantiation]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We are careful never to make a MethodInst that has, as its meth_id, another
MethodInst.
For example, consider
f :: forall a. Eq a => forall b. Ord b => a -> b
At a call to f, at say [Int, Bool], it's tempting to translate the call to
f_m1
where
f_m1 :: forall b. Ord b => Int -> b
f_m1 = f Int dEqInt
f_m2 :: Int -> Bool
f_m2 = f_m1 Bool dOrdBool
But notice that f_m2 has f_m1 as its meth_id. Now the danger is that if we do
a tcSimplCheck with a Given f_mx :: f Int dEqInt, we may make a binding
f_m1 = f_mx
But it's entirely possible that f_m2 will continue to float out, because it
mentions no type variables. Result, f_m1 isn't in scope.
Here's a concrete example that does this (test tc200):
class C a where
f :: Eq b => b -> a -> Int
baz :: Eq a => Int -> a -> Int
instance C Int where
baz = f
Current solution: only do the "method sharing" thing for the first type/dict
application, not for the iterated ones. A horribly subtle point.
Revision Changes Path
1.191 +42 -5 fptools/ghc/compiler/typecheck/TcExpr.lhs
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
