1. 30 Jan, 2013 1 commit
  2. 15 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Tidy up FunDeps.oclose · ecddaca1
      Simon Peyton Jones authored
      It turned out that FunDeps.oclose was unused. So
      * Remove oclose
      * Rename oclose1 to oclose
      * Move growThetaTyVars to FunDeps (from TcMType),
        because the comments treat it with oclose
      * Move quantifyPred to TcSimplify (from TcMType),
        because it seemed orphaned
  3. 08 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer the ambiguity test for user type signatures · 97db0edc
      Simon Peyton Jones authored
      Two main changes. First, re-engineer the ambiguity test.  Previously
      TcMType.checkAmbiguity used a rather syntactic test to detect some
      types that are certainly ambiguous.  But a much easier test is available,
      and it is used for inferred types in TcBinds. Namely
          <type> is ambiguous
         <type> `TcUnify.isSubType` <type>
      fails to hold, where "isSubType" means "is provably more polymorphic than".
            C a => Int
      is ambiguous, because isSubType instantiates the (C a => Int)
      to (C alpha => Int) and then tries to deduce (C alpha) from (C a). This is
      Martin Sulzmann's definition of ambiguity.  (Defn 10 of "Understanding
      functional dependencies via constraint handling rules", JFP.)
      This change is neat, reduces code, and correctly rejects more programs.
      However is *is* just possible to have a useful program that would be
      rejected. For example
                class C a b
                f :: C Int b => Int -> Int
      Here 'f' would be rejected as having an ambiguous type. But it is
      just possible that, at a *call* site there might be an instance
      declaration  instance C Int b, which does not constrain 'b' at all.
      This is pretty strange -- why is 'b' overloaded at all? -- but it's
      possible, so I also added a flag -XAllowAmbiguousTypes that simply
      removes the ambiguity check.  Let's see if anyone cares.  Meanwhile
      the earlier error report will be useful for everyone else.
      A handful of regression tests had to be adjusted as a result, because
      they used ambiguous types, somewhat accidentally.
      Second, split TcMType (already too large) into two
        * TcMType: a low-level module dealing with monadic operations like
          zonking, creating new evidence variables, etc
        * TcValidity: a brand-new higher-level module dealing with
          validity checking for types: checkValidType, checkValidInstance,
          checkFamInstPats etc
      Apart from the fact that TcMType was too big, this allows TcValidity
      to import TcUnify(tcSubType) without causing a loop.
  4. 01 Jan, 2013 1 commit
  5. 24 Dec, 2012 1 commit
  6. 19 Oct, 2012 1 commit
    • Simon Peyton Jones's avatar
      In approximateWC, do not float contraints out of an implication with equalities · 6a58aa0c
      Simon Peyton Jones authored
      Jacques Garrigue pointed out that GHC 7.6 was accepting GADT programs
      that our OutsideIn paper said would be rejected.  The reason was that
      approximateWC was being too aggressive about floating; see Note
      [approximateWC] in TcSimplify.
      This simple patch fixes that, but it is (of course) not backward
      compatible; a few GADT programs that were (erroneously) accepted
      before are now rejected, and will need a type signature.  This could
      be under flag control, but I'd rather just make it compulsory.
         data T a where
           TInt :: T Int
           MkT :: T a
         f TInt = 3::Int
      Here f (with no type signature) is current accepted, with inferred type
       f :: T a -> Int
      but should be rejected
  7. 15 Oct, 2012 1 commit
    • Simon Peyton Jones's avatar
      Add kind-defaulting in simplifyInfer (fixes Trac #7332) · 74358251
      Simon Peyton Jones authored
      The basic point here is described in TcSimplify
         Note [Promote _and_ default when inferring]
      The new thing is that, when figuring out the predicates
      to abstact over in simplifyInfer, we must default OpenKind
      to *, just as we do in quantifyTyVar. I had not realised
      how important this was until Oleg came up with Trac #7332.
      As usual I did some refactoring, so the patch affects
      many more lines than strictly necessary.
  8. 04 Oct, 2012 1 commit
  9. 28 Sep, 2012 1 commit
  10. 18 Sep, 2012 2 commits
  11. 17 Sep, 2012 3 commits
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Another refactoring of constraints · d30b9cf4
      Simon Peyton Jones authored
      1. Rejig CtLoc
         * CtLoc is now *not* parameterised (much simpler)
         * CtLoc includes the "depth" of the constraint
         * CtLoc includes the TcLclEnv at the birthplace
           That gives (a) the SrcSpan, (b) the [ErrCtxt]
           (c) the [TcIdBinder]
         * The CtLoc of a constraint is no longer in its CtEvidence
         * Where we passed 'depth' before, now we pass CtLoc
      2. Some significant refactoring in TcErrors
         * Get rid of cec_extra
         * Traverse every constraint, so that we can be
           sure to generate bindings where necessary.
           (This was really a lurking bug before.)
      3. Merge zonking into TcCanonical.  This turned out to be
         almost trivial; just a small change to TcCanonical.flattenTyVar.
         The nice consequence is that we don't need to zonk a constraint
         before solving it; instead it gets zonked "on the fly" as it were.
    • Simon Peyton Jones's avatar
      Add type "holes", enabled by -XTypeHoles, Trac #5910 · 8a9a7a8c
      Simon Peyton Jones authored
      This single commit combines a lot of work done by
      Thijs Alkemade <thijsalkemade@gmail.com>, plus a slew
      of subsequent refactoring by Simon PJ.
      The basic idea is
      * Add a new expression form "_", a hole, standing for a not-yet-written expression
      * Give a useful error message that
         (a) gives the type of the hole
         (b) gives the types of some enclosing value bindings that
             mention the hole
      Driven by this goal I did a LOT of refactoring in TcErrors, which in turn
      allows us to report enclosing value bindings for other errors, not just
      holes.  (Thijs rightly did not attempt this!)
      The major data type change is a new form of constraint
        data Ct = ...
          	  | CHoleCan {
          	      cc_ev       :: CtEvidence,
          	      cc_hole_ty  :: TcTauType,
          	      cc_depth    :: SubGoalDepth }
      I'm still in two minds about whether this is the best plan. Another
      possibility would be to have a predicate type for holes, somthing like
         class Hole a where
           holeValue :: a
      It works the way it is, but there are some annoying special cases for
      CHoleCan (just grep for "CHoleCan").
  12. 06 Sep, 2012 1 commit
  13. 03 Sep, 2012 3 commits
  14. 01 Sep, 2012 2 commits
  15. 30 Aug, 2012 1 commit
    • Simon Peyton Jones's avatar
      A raft more changes, · 2b69233d
      Simon Peyton Jones authored
       * simplifying and tidying up canonicalisation,
       * removing the flat cache altogether
       * making the FunEq worklist into a deque
  16. 29 Aug, 2012 1 commit
  17. 28 Aug, 2012 2 commits
  18. 21 Aug, 2012 1 commit
  19. 15 Aug, 2012 1 commit
  20. 23 Jul, 2012 1 commit
    • Simon Peyton Jones's avatar
      Numerous small changes to the constraint solver · 9c0a6bbb
      Simon Peyton Jones authored
      The main thing is that we now keep unsolved Derived constraints in the
      wc_flats of a WantedConstraints, rather than discarding them each time.
      This actually fixes a poential (admittedly obscure) bug, when we currently
      discard a superclass constraint, and may never re-generate it, and may
      thereby miss a functional dependency.
      Instead, reportErrors filters out Derived constraints that we don't want
      to report.
      The other changes are all small refactorings following our walk-through.
  21. 19 Jul, 2012 2 commits
  22. 14 Jul, 2012 1 commit
    • Simon Peyton Jones's avatar
      Do not discard insoluble constraints in simplifyInfer · c1f01e35
      Simon Peyton Jones authored
      Before -fdefer-type-errors there we no insolubles
      (because we'd have failed before then), but with -fdefer-type-errors
      there can be.  The code is acutally a bit simpler: we just call
      emitConstraints, and eliminate the bogus-looking emitWC from TcRnMonad.
      There's a bit more tidying up to do, concerning the places we use
      keepWanted, but I need to talk to Dimitrios about that.
      Meanwhile this fixes Trac #7023
  23. 21 Jun, 2012 1 commit
  24. 13 Jun, 2012 1 commit
    • Simon Peyton Jones's avatar
      Simplify the implementation of Implicit Parameters · 5a8ac0f8
      Simon Peyton Jones authored
      This patch re-implements implicit parameters via a class
      with a functional dependency:
          class IP (n::Symbol) a | n -> a where
            ip :: a
      This definition is in the library module GHC.IP. Notice
      how it use a type-literal, so we can have constraints like
         IP "x" Int
      Now all the functional dependency machinery works right to make
      implicit parameters behave as they should.
      Much special-case processing for implicit parameters can be removed
      entirely. One particularly nice thing is not having a dedicated
      "original-name cache" for implicit parameters (the nsNames field of
      NameCache).  But many other cases disappear:
        * BasicTypes.IPName
        * IPTyCon constructor in Tycon.TyCon
        * CIPCan constructor  in TcRnTypes.Ct
        * IPPred constructor  in Types.PredTree
      Implicit parameters remain special in a few ways:
       * Special syntax.  Eg the constraint (IP "x" Int) is parsed
         and printed as (?x::Int).  And we still have local bindings
         for implicit parameters, and occurrences thereof.
       * A implicit-parameter binding  (let ?x = True in e) amounts
         to a local instance declaration, which we have not had before.
         It just generates an implication contraint (easy), but when
         going under it we must purge any existing bindings for
         ?x in the inert set.  See Note [Shadowing of Implicit Parameters]
         in TcSimplify
       * TcMType.sizePred classifies implicit parameter constraints as size-0,
         as before the change
      There are accompanying patches to libraries 'base' and 'haddock'
      All the work was done by Iavor Diatchki
  25. 08 Jun, 2012 1 commit
    • dimitris's avatar
      Significant refactoring of TcSimplify, in particular simplifyInfer and · 3891a056
      dimitris authored
      simplifyTop, code beautification etc. Important things:
      (a) New top-level defaulting plan, gotten rid of the SimplContext field.
          See Note [Top-level Defaulting Plan]
      (b) Serious bug fix in the floatEqualities mechanism
          See Note [Extra TcS Untouchables],[Float Equalities out of Implications]
      The changes are mostly confined in TcSimplify but there is a
      simplification wave affecting other modules as well.
  26. 07 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Yet another major refactoring of the constraint solver · dd7522c3
      Simon Peyton Jones authored
      This is the result of Simon and Dimitrios doing a code walk through.
      There is no change in behaviour, but the structure is much better.
      Main changes:
      * Given constraints contain an EvTerm not an EvVar
      * Correspondingly, TcEvidence is a recursive types that uses
        EvTerms rather than EvVars
      * Rename CtFlavor to CtEvidence
      * Every CtEvidence has a ctev_pred field.  And use record fields
        consistently for CtEvidence
      * The solved-constraint fields of InertSet (namely inert_solved and
        inert_solved_funeqs) contain CtEvidence, not Ct
      There is a long cascade of follow-on changes.
  27. 16 Apr, 2012 1 commit
    • Simon Peyton Jones's avatar
      Simplify the typechecking of RULES · 5aa1ae24
      Simon Peyton Jones authored
      Not only does this fix Trac #5853, but it also eliminate
      the horrid SimplEqsOnly part of the constraint simplifier.
      The new plan is described in TcRules
       Note [Simplifying RULE constraints]
  28. 10 Apr, 2012 1 commit
  29. 02 Apr, 2012 1 commit
  30. 30 Mar, 2012 2 commits
  31. 29 Mar, 2012 1 commit