1. 11 Feb, 2011 1 commit
  2. 09 Feb, 2011 3 commits
  3. 01 Feb, 2011 1 commit
  4. 26 Jan, 2011 1 commit
  5. 25 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Fix Trac #4917: try a bit harder to unify on-the-fly · 1add108e
      simonpj@microsoft.com authored
      This is generally a modest improvement but, more important,
      it fixes a "unify-under-forall" problem.  See Note [Avoid deferring].
      
      There's still a lurking unsatisfactory-ness in that we can't
      defer arbitrary constraints that are trapped under a forall.
      1add108e
  6. 13 Jan, 2011 2 commits
  7. 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
  8. 10 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Do dependency analysis when kind-checking type declarations · 6ea06bbf
      simonpj@microsoft.com authored
      This patch fixes Trac #4875.  The main point is to do dependency
      analysis on type and class declarations, and kind-check them in
      dependency order, so as to improve error messages.
      
      This patch means that a few programs that would typecheck before won't
      typecheck any more; but before we were (naughtily) going beyond
      Haskell 98 without any language-extension flags, and Trac #4875
      convinces me that doing so is a Bad Idea.
      
      Here's an example that won't typecheck any more
             data T a b = MkT (a b)
             type F k = T k Maybe
      
      If you look at T on its own you'd default 'a' to kind *->*;
      and then kind-checking would fail on F.
      
      But GHC currently accepts this program beause it looks at
      the *occurrences* of T.
      6ea06bbf
  9. 24 Dec, 2010 1 commit
  10. 22 Dec, 2010 3 commits
    • simonpj@microsoft.com's avatar
      Implement fuzzy matching for the renamer · 820ddd55
      simonpj@microsoft.com authored
      ...so that you get helpful suggestions when you mis-spell a name
      Based on Max's patch in Trac #2442, but heavily refactored.
      820ddd55
    • simonpj@microsoft.com's avatar
      Tidy up rebindable syntax for MDo · ba05282d
      simonpj@microsoft.com authored
      For a long time an 'mdo' expression has had a SyntaxTable
      attached to it.  However, we're busy deprecating SyntaxTables
      in favour of rebindable syntax attached to individual Stmts,
      and MDoExpr was totally inconsistent with DoExpr in this
      regard.
      
      This patch tidies it all up.  Now there's no SyntaxTable on
      MDoExpr, and 'modo' is generally handled much more like 'do'.
      
      There is resulting small change in behaviour: now MonadFix is
      required only if you actually *use* recursion in mdo. This
      seems consistent with the implicit dependency analysis that
      is done for mdo.
      
      Still to do:
        * Deal with #4148 (this patch is on the way)
        * Get rid of the last remaining SyntaxTable on HsCmdTop
      ba05282d
    • simonpj@microsoft.com's avatar
      Make mkDFunUnfolding more robust · 3e0a7b9f
      simonpj@microsoft.com authored
      It now uses tcSplitDFunTy, which is designed for the purpose and
      allows arbitrary argument types to the dfun, rather than
      tcSplitSigmaTy.  This generality is used in DPH, which has
      internally-generated dfuns with impliciation-typed arguments.
      
      To do this I had to make tcSplitDFunTy return the number of
      arguments, so there are some minor knock-on effects in other
      modules.
      3e0a7b9f
  11. 21 Dec, 2010 1 commit
  12. 01 Nov, 2010 1 commit
  13. 18 Dec, 2010 1 commit
  14. 15 Dec, 2010 2 commits
  15. 14 Dec, 2010 3 commits
  16. 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
  17. 10 Dec, 2010 1 commit
  18. 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
  19. 03 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix up TcInstDcls · 081632b8
      simonpj@microsoft.com authored
      I really don't know how this module got left out of my last
      patch, namely
        Thu Dec  2 12:35:47 GMT 2010  simonpj@microsoft.com
        * Re-jig simplifySuperClass (again)
      
      I suggest you don't pull either the patch above, or this
      one, unless you really have to.  I'm not fully confident
      that it works properly yet.  Ran out of time. Sigh.
      081632b8
  20. 02 Dec, 2010 5 commits
  21. 01 Nov, 2010 1 commit
  22. 24 Nov, 2010 1 commit
  23. 18 Nov, 2010 3 commits
  24. 17 Nov, 2010 1 commit
  25. 16 Nov, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Warn a bit less often about unlifted bindings. · 67157c5c
      simonpj@microsoft.com authored
      Warn when
         (a) a pattern bindings binds unlifted values
         (b) it has no top-level bang
         (c) the RHS has a *lifted* type
      
      Clause (c) is new, argued for by Simon M
      
      Eg     x# = 4# + 4#      -- No warning
             (# a,b #) = blah  -- No warning
             I# x = blah       -- Warning
      67157c5c
  26. 15 Nov, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Deriving Typeable changes · bf6dd833
      simonpj@microsoft.com authored
      * Fix a bug that led to a crash with
          data family T a
          deriving Functor T
      
      * Allow deriving Typeable for data families
          data family T a
          deriving Typeable1 T
      
      * Some refactoring and tidying
      bf6dd833