Improve handling of implicit parameters
authorsimonpj@microsoft.com <unknown>
Fri, 24 Nov 2006 12:21:20 +0000 (12:21 +0000)
committersimonpj@microsoft.com <unknown>
Fri, 24 Nov 2006 12:21:20 +0000 (12:21 +0000)
commit2e9952b703341351298739b5d4f869fbdfc8490e
treea2b3954aa2d62842236306df032910d9aa68f855
parentdfcbc18e016540cb136ec3298a07a4a55b488db0
Improve handling of implicit parameters

A message to Haskell Cafe from Grzegorz Chrupala made me realise that
GHC was not handling implicit parameters correctly, when it comes to
choosing the variables to quantify, and ambiguity tests.  Here's the
note I added to TcSimplify:

Note [Implicit parameters and ambiguity]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
What type should we infer for this?
f x = (show ?y, x::Int)
Since we must quantify over the ?y, the most plausible type is
f :: (Show a, ?y::a) => Int -> (String, Int)
But notice that the type of the RHS is (String,Int), with no type
varibables mentioned at all!  The type of f looks ambiguous.  But
it isn't, because at a call site we might have
let ?y = 5::Int in f 7
and all is well.  In effect, implicit parameters are, well, parameters,
so we can take their type variables into account as part of the
"tau-tvs" stuff.  This is done in the function 'FunDeps.grow'.

The actual changes are in FunDeps.grow, and the tests are
tc219, tc219
compiler/typecheck/TcSimplify.lhs
compiler/types/FunDeps.lhs