Roman

OK as we agreed, I've pushed patches that provoke a Lint error in DPH, for 
reasons you know.  You're going to fix the vectoriser.

The main patch, which has pointers to the relevant documentation, is below.

Phew!

Simon



Mon Dec 13 09:15:11 PST 2010  
[email protected]<mailto:[email protected]>

  * Fix recursive superclasses (again).  Fixes Trac #4809.



  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 -7 +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 -9 +23

    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 -29 +15

    M ./compiler/hsSyn/HsBinds.lhs -4 +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 -8 +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 -3 +11

    M ./compiler/typecheck/TcClassDcl.lhs -17 +7

    M ./compiler/typecheck/TcDeriv.lhs -21 +22

    M ./compiler/typecheck/TcEnv.lhs -2 +2

    M ./compiler/typecheck/TcErrors.lhs -9 +10

    M ./compiler/typecheck/TcHsSyn.lhs -2 +2

    M ./compiler/typecheck/TcHsType.lhs -28 +30

    M ./compiler/typecheck/TcInstDcls.lhs -143 +178

    M ./compiler/typecheck/TcInteract.lhs -3 +2

    M ./compiler/typecheck/TcMType.lhs -49 +34

    M ./compiler/typecheck/TcSMonad.lhs -5 +3

    M ./compiler/typecheck/TcSimplify.lhs -115 +5

    M ./compiler/typecheck/TcType.lhs -5 +8

    M ./compiler/typecheck/TcUnify.lhs -7 +5

    M ./compiler/types/InstEnv.lhs -8 +18

    M ./compiler/vectorise/Vectorise/Type/PADict.hs -1 +2

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to