[project @ 2001-02-20 09:42:50 by simonpj]
authorsimonpj <unknown>
Tue, 20 Feb 2001 09:42:50 +0000 (09:42 +0000)
committersimonpj <unknown>
Tue, 20 Feb 2001 09:42:50 +0000 (09:42 +0000)
commit22ffc06ab94bba69b7e45d90ccd5885d9fcc456e
tree005537041a352e468cfefc0f292b100d0415d007
parent52eed22df83f01b4fbe3d1c67abc5e3893e47d39
[project @ 2001-02-20 09:42:50 by simonpj]
Typechecking [TcModule, TcBinds, TcHsSyn, TcInstDcls, TcSimplify]
~~~~~~~~~~~~
* Fix a bug in TcSimplify that broke functional dependencies.
  Interleaving unification and context reduction is trickier
  than I thought.  Comments in the code amplify.

* Fix a functional-dependency bug, that meant that this pgm:
class C a b | a -> b where f :: a -> b

g :: (C a b, Eq b) => a -> Bool
g x = f x == f x
  gave an ambiguity error report.  I'm afraid I've forgotten
  what the problem was.

* Correct the implementation of the monomorphism restriction,
  in TcBinds.generalise.  This fixes Marcin's bug report:
test1 :: Eq a => a -> b -> b
test1 x y = y

test2 = test1 (3::Int)
  Previously we were erroneously inferring test2 :: () -> ()

* Make the "unf_env" that is looped round in TcModule go round
  in a big loop, not just round tcImports.  This matters when
  we have mutually recursive modules, so that the Ids bound in
  the source code may appear in the imports.  Sigh.  But no big
  deal.

  It does mean that you have to be careful not to call isLocalId,
  isDataConId etc, because they consult the IdInfo of an Id, which
  in turn may be determined by the loop-tied unf_env.
ghc/compiler/typecheck/TcBinds.lhs
ghc/compiler/typecheck/TcHsSyn.lhs
ghc/compiler/typecheck/TcInstDcls.lhs
ghc/compiler/typecheck/TcModule.lhs
ghc/compiler/typecheck/TcSimplify.lhs