• simonpj@microsoft.com's avatar
    Fix recursive superclasses (again). Fixes Trac #4809. · a3bab050
    simonpj@microsoft.com authored
    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.
    a3bab050
TcSMonad.lhs 35.8 KB