1. 17 Feb, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Use "on the spot" solving for fundeps · 50d02935
      simonpj@microsoft.com authored
      When we spot an equality arising from a functional dependency,
      we now use that equality (a "wanted") to rewrite the work-item
      constraint right away.  This avoids two dangers
      
       Danger 1: If we send the original constraint on down the pipeline
                 it may react with an instance declaration, and in delicate
      	   situations (when a Given overlaps with an instance) that
      	   may produce new insoluble goals: see Trac #4952
      
       Danger 2: If we don't rewrite the constraint, it may re-react
                 with the same thing later, and produce the same equality
                 again --> termination worries.
      
      To achieve this required some refactoring of FunDeps.lhs (nicer
      now!).  
      
      This patch also contains a couple of unrelated improvements
      
      * A bad bug in TcSMonad.nestImplicTcS whereby the Tcs tyvars
        of an outer implication were not untouchable inside
      
      * Improved logging machinery for the type constraint solver;
        use -ddump-cs-trace (probably with a wider default line width
        -dppr-cols=200 or something)
      50d02935
  2. 11 Feb, 2011 2 commits
  3. 12 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Major refactoring of the type inference engine · 27310213
      simonpj@microsoft.com authored
      This patch embodies many, many changes to the contraint solver, which
      make it simpler, more robust, and more beautiful.  But it has taken
      me ages to get right. The forcing issue was some obscure programs
      involving recursive dictionaries, but these eventually led to a
      massive refactoring sweep.
      
      Main changes are:
       * No more "frozen errors" in the monad.  Instead "insoluble
         constraints" are now part of the WantedConstraints type.
      
       * The WantedConstraint type is a product of bags, instead of (as
         before) a bag of sums.  This eliminates a good deal of tagging and
         untagging.
      
       * This same WantedConstraints data type is used
           - As the way that constraints are gathered
           - As a field of an implication constraint
           - As both argument and result of solveWanted
           - As the argument to reportUnsolved
      
       * We do not generate any evidence for Derived constraints. They are
         purely there to allow "impovement" by unifying unification
         variables.
      
       * In consequence, nothing is ever *rewritten* by a Derived
         constraint.  This removes, by construction, all the horrible
         potential recursive-dictionary loops that were making us tear our
         hair out.  No more isGoodRecEv search either. Hurrah!
      
       * We add the superclass Derived constraints during canonicalisation,
         after checking for duplicates.  So fewer superclass constraints
         are generated than before.
      
       * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
         SkolemInfo lives in the GivenLoc of the Implication, where it
         can be tidied, zonked, and substituted nicely.  This alone is
         a major improvement.
      
       * Tidying is improved, so that we tend to get t1, t2, t3, rather
         than t1, t11, t111, etc
      
         Moreover, unification variables are always printed with a digit
         (thus a0, a1, etc), so that plain 'a' is available for a skolem
         arising from a type signature etc. In this way,
           (a) We quietly say which variables are unification variables,
               for those who know and care
           (b) Types tend to get printed as the user expects.  If he writes
                   f :: a -> a
                   f = ...blah...
               then types involving 'a' get printed with 'a', rather than
               some tidied variant.
      
       * There are significant improvements in error messages, notably
         in the "Cannot deduce X from Y" messages.
      27310213
  4. 14 Dec, 2010 1 commit
  5. 13 Dec, 2010 1 commit
    • 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
  6. 10 Dec, 2010 1 commit
  7. 09 Dec, 2010 1 commit
    • dimitris@microsoft.com's avatar
      Moved canonicalisation inside solveInteract · ef6d82a4
      dimitris@microsoft.com authored
      Moreover canonicalisation now is "clever", i.e. it never canonicalizes a class 
      constraint if it can already discharge it from some other inert or previously
      encountered constraints. See Note [Avoiding the superclass explosion]
      ef6d82a4
  8. 02 Dec, 2010 3 commits
  9. 15 Nov, 2010 1 commit
  10. 12 Nov, 2010 1 commit
    • simonpj@microsoft.com's avatar
      A (final) re-engineering of the new typechecker · c80364f8
      simonpj@microsoft.com authored
      Regression testing and user feedback for GHC 7.0 taught
      us a lot.  This patch fixes numerous small bugs, and some
      major ones (eg Trac #4484, #4492), and improves type
      error messages.
      
      The main changes are:
      
      * Entirely remove the "skolem equivalance class" stuff;
        a very useful simplification
      
      * Instead, when flattening "wanted" constraints we generate
        unification variables (not flatten-skolems) for the
        flattened type function application
      
      * We then need a fixup pass at the end, TcSimplify.solveCTyFunEqs,
        which resolves any residual equalities of form
            F xi ~ alpha
      
      * When we come across a definite failure (e.g. Int ~ [a]),
        we now defer reporting the error until the end, in case we
        learn more about 'a'.  That is particularly important for
        occurs-check errors.  These are called "frozen" type errors.
      
      * Other improvements in error message generation.
      
      * Better tracing messages
      c80364f8
  11. 22 Oct, 2010 1 commit
  12. 20 Oct, 2010 2 commits
  13. 19 Oct, 2010 3 commits
  14. 18 Oct, 2010 1 commit
  15. 15 Oct, 2010 1 commit
  16. 14 Oct, 2010 1 commit
  17. 11 Oct, 2010 1 commit
  18. 08 Oct, 2010 1 commit
  19. 15 Oct, 2010 1 commit
  20. 13 Oct, 2010 1 commit
  21. 08 Oct, 2010 2 commits
  22. 07 Oct, 2010 1 commit
  23. 06 Oct, 2010 1 commit
  24. 04 Oct, 2010 1 commit
  25. 17 Sep, 2010 2 commits
  26. 13 Sep, 2010 2 commits