patch applied (ghc-7.0/ghc): MERGED: Fix recursive superclasses (again). Fixes Trac #4809.

[Ian Lynagh]

Tue Dec 14 10:00:26 PST 2010  Ian Lynagh <igloo at earth.li>
  * MERGED: Fix recursive superclasses (again).  Fixes Trac #4809.
  simonpj at microsoft.com**20101213171511
   Ignore-this: b91651397918fd8f0183812f9a070073
  
   This patch finally deals with the super-delicate question of
   superclases in possibly-recursive dictionaries.  The key idea
   is the DFun Superclass Invariant (see TcInstDcls):
  
        In the body of a DFun, every superclass argument to the
        returned dictionary is
          either   * one of the arguments of the DFun,
          or       * constant, bound at top level
  
   To establish the invariant, we add new "silent" superclass
   argument(s) to each dfun, so that the dfun does not do superclass
   selection internally.  There's a bit of hoo-ha to make sure that
   we don't print those silent arguments in error messages; a knock
   on effect was a change in interface-file format.
  
   A second change is that instead of the complex and fragile
   "self dictionary binding" in TcInstDcls and TcClassDcl,
   using the same mechanism for existential pattern bindings.
   See Note [Subtle interaction of recursion and overlap] in TcInstDcls
   and Note [Binding when looking up instances] in InstEnv.
  
   Main notes are here:
  
     * Note [Silent Superclass Arguments] in TcInstDcls,
       including the DFun Superclass Invariant
  
   Main code changes are:
  
     * The code for MkId.mkDictFunId and mkDictFunTy
  
     * DFunUnfoldings get a little more complicated;
       their arguments are a new type DFunArg (in CoreSyn)
  
     * No "self" argument in tcInstanceMethod
     * No special tcSimplifySuperClasss
     * No "dependents" argument to EvDFunApp
  
   IMPORTANT
      It turns out that it's quite tricky to generate the right
      DFunUnfolding for a specialised dfun, when you use SPECIALISE
      INSTANCE.  For now I've just commented it out (in DsBinds) but
      that'll lose some optimisation, and I need to get back to
      this.

    M ./compiler/basicTypes/Id.lhs -3 +8
    M ./compiler/basicTypes/IdInfo.lhs -6 +14
    M ./compiler/basicTypes/MkId.lhs -12 +24
    M ./compiler/coreSyn/CoreFVs.lhs -1 +1
    M ./compiler/coreSyn/CoreSubst.lhs -1 +3
    M ./compiler/coreSyn/CoreSyn.lhs -8 +26
    M ./compiler/coreSyn/CoreTidy.lhs -1 +1
    M ./compiler/coreSyn/CoreUnfold.lhs -4 +6
    M ./compiler/coreSyn/CoreUtils.lhs -1 +1
    M ./compiler/coreSyn/PprCore.lhs -2 +6
    M ./compiler/deSugar/DsBinds.lhs -22 +8
    M ./compiler/hsSyn/HsBinds.lhs -2 +1
    M ./compiler/hsSyn/HsExpr.lhs-boot +4
    M ./compiler/hsSyn/HsPat.lhs-boot +1
    M ./compiler/iface/BinIface.hs -2 +13
    M ./compiler/iface/IfaceSyn.lhs -6 +7
    M ./compiler/iface/MkIface.lhs -2 +2
    M ./compiler/iface/TcIface.lhs -3 +6
    M ./compiler/main/TidyPgm.lhs -1 +1
    M ./compiler/simplCore/Simplify.lhs -1 +1
    M ./compiler/typecheck/Inst.lhs -4 +12
    M ./compiler/typecheck/TcClassDcl.lhs -15 +6
    M ./compiler/typecheck/TcDeriv.lhs -21 +22
    M ./compiler/typecheck/TcEnv.lhs -2 +2
    M ./compiler/typecheck/TcErrors.lhs -9 +10
    M ./compiler/typecheck/TcHsType.lhs -28 +30
    M ./compiler/typecheck/TcInstDcls.lhs -147 +176
    M ./compiler/typecheck/TcMType.lhs -45 +32
    M ./compiler/typecheck/TcSMonad.lhs -3 +3
    M ./compiler/typecheck/TcSimplify.lhs -55 +5
    M ./compiler/typecheck/TcType.lhs -5 +8
    M ./compiler/typecheck/TcUnify.lhs -8 +5
    M ./compiler/types/InstEnv.lhs -7 +17
    M ./compiler/vectorise/Vectorise/Type/PADict.hs -1 +2

View patch online:
http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=20101214180026-3fd76-e56d10aec0402a072393b765d6c090476d76b822.gz