1. 19 Dec, 2011 1 commit
  2. 05 Dec, 2011 1 commit
    • Simon Peyton Jones's avatar
      Allow full constraint solving under a for-all (Trac #5595) · 2e6dcdf7
      Simon Peyton Jones authored
      The main idea is that when we unify
          forall a. t1  ~  forall a. t2
      we get constraints from unifying t1~t2 that mention a.
      We are producing a coercion witnessing the equivalence of
      the for-alls, and inside *that* coercion we need bindings
      for the solved constraints arising from t1~t2.
      
      We didn't have way to do this before.  The big change is
      that here's a new type TcEvidence.TcCoercion, which is
      much like Coercion.Coercion except that there's a slot
      for TcEvBinds in it.
      
      This has a wave of follow-on changes. Not deep but broad.
      
      * New module TcEvidence, which now contains the HsWrapper
        TcEvBinds, EvTerm etc types that used to be in HsBinds
      
      * The typechecker works exclusively in terms of TcCoercion.
      
      * The desugarer converts TcCoercion to Coercion
      
      * The main payload is in TcUnify.unifySigmaTy. This is the
        function that had a gross hack before, but is now beautiful.
      
      * LCoercion is gone!  Hooray.
      
      Many many fiddly changes in conssequence.  But it's nice.
      2e6dcdf7
  3. 28 Nov, 2011 1 commit
    • dimitris's avatar
      Solved goal caching and zonking optimisations. · 4bc84da3
      dimitris authored
      1) Stopped rewriting and caching solveds in the inerts because
      profiling showed that a lot of time was spent on rewriting
      already solved goals.
      
      2) Optimisations in zonkEvBinds for common-case
      evidence bindings generated from the constraint solver.
      
      3) Now solved goals cache their evidence terms, so that we can more
      aggressively optimize Refl coercions during constraint solving.
      This patch also includes a rewrite of rewriteInertEqsFromInertEq
      which greatly improves its efficiency.
      4bc84da3
  4. 17 Nov, 2011 1 commit
  5. 16 Nov, 2011 1 commit
  6. 11 Nov, 2011 1 commit
    • dreixel's avatar
      New kind-polymorphic core · 09015be8
      dreixel authored
      This big patch implements a kind-polymorphic core for GHC. The current
      implementation focuses on making sure that all kind-monomorphic programs still
      work in the new core; it is not yet guaranteed that kind-polymorphic programs
      (using the new -XPolyKinds flag) will work.
      
      For more information, see http://haskell.org/haskellwiki/GHC/Kinds
      09015be8
  7. 04 Nov, 2011 1 commit
  8. 07 Sep, 2011 2 commits
  9. 06 Sep, 2011 2 commits
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
      
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
      9729fe7c
    • batterseapower's avatar
      6bad38a4
  10. 08 Aug, 2011 1 commit
  11. 03 Aug, 2011 3 commits
  12. 23 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      A nice tidy-up for CvSubst and liftCoSubst · 525aca2c
      Simon Peyton Jones authored
      A "lifting substitition" takes a *type* to a *coercion*, using a
      substitution that takes a *type variable* to a *coercion*.  We were
      using a CvSubst for this purpose, which was an awkward exception: in
      every other use of CvSubst, type variables map only to types.
      
      Turned out that Coercion.liftCoSubst is quite a small function, so I
      rewrote it with a special substitution type Coercion.LiftCoSubst, just
      for that purpose.  In doing so I found that the function itself was
      bizarrely over-complicated ... a direct result of mis-using CvSubst.
      
      So this patch makes it all simpler, faster, and easier to understand.
      No bugs fixed though!
      525aca2c
  13. 15 Jul, 2011 1 commit
  14. 12 May, 2011 1 commit
    • Simon Peyton Jones's avatar
      The final batch of changes for the new coercion representation · c8c2f6bb
      Simon Peyton Jones authored
      * Fix bugs in the packing and unpacking of data
        constructors with equality predicates in their types
      
      * Remove PredCo altogether; instead, coercions between predicated
        types (like  (Eq a, [a]~b) => blah) are treated as if they
        were precisely their underlying representation type
             Eq a -> ((~) [a] b) -> blah
        in this case
      
      * Similarly, Type.coreView no longer treats equality
        predciates specially.
      
      * Implement the cast-of-coercion optimisation in
        Simplify.simplCoercionF
      
      Numerous other small bug-fixes and refactorings.
      
      Annoyingly, OptCoercion had Windows line endings, and this
      patch switches to Unix, so it looks as if every line has changed.
      c8c2f6bb
  15. 19 Apr, 2011 1 commit
    • Simon Peyton Jones's avatar
      This BIG PATCH contains most of the work for the New Coercion Representation · fdf86568
      Simon Peyton Jones authored
      See the paper "Practical aspects of evidence based compilation in System FC"
      
      * Coercion becomes a data type, distinct from Type
      
      * Coercions become value-level things, rather than type-level things,
        (although the value is zero bits wide, like the State token)
        A consequence is that a coerion abstraction increases the arity by 1
        (just like a dictionary abstraction)
      
      * There is a new constructor in CoreExpr, namely Coercion, to inject
        coercions into terms
      fdf86568
  16. 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
  17. 06 Oct, 2010 1 commit
  18. 16 Sep, 2010 1 commit
  19. 13 Sep, 2010 1 commit
  20. 14 Jun, 2010 1 commit
  21. 01 Mar, 2010 1 commit
  22. 04 Jan, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Substantial improvements to coercion optimisation · b06d623b
      simonpj@microsoft.com authored
      The main purpose of this patch is to add a bunch of new rules
      to the coercion optimiser.  They are documented in the (revised)
      Appendix of the System FC paper.  
      
      Some code has moved about:
      
      - OptCoercion is now a separate module, mainly because it
        now uses tcMatchTy, which is defined in Unify, so OptCoercion
        must live higehr up in the hierarchy
      
      - Functions that manipulate Kinds has moved from 
        Type.lhs to Coercion.lhs.  Reason: the function typeKind
        now needs to call coercionKind.  And in any case, a Kind is
        a flavour of Type, so it builds on top of Type; indeed Coercions
        and Kinds are both flavours of Type.
      
        This change required fiddling with a number of imports, hence
        the one-line changes to otherwise-unrelated modules
      
      - The representation of CoTyCons in TyCon has changed.   Instead of
        an extensional representation (a kind checker) there is now an
        intensional representation (namely TyCon.CoTyConDesc).  This was
        needed for one of the new coercion optimisations.
      b06d623b
  23. 16 Dec, 2009 3 commits
  24. 11 Dec, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Use full equality for CSE · 21eeb926
      simonpj@microsoft.com authored
      In CSE we were getting lots of apprarently-unequal expressions with
      the same hash code.  In fact they were perfectly equal -- but we were
      using a cheap-and-cheerful equality tests for CoreExpr that said False
      for any lambda expression!
      
      This patch adds a proper equality test for Core, with alpha-renaming.
      It's easy to do, and will avoid silly cases of CSE failing to fire.
      
      We should get less of this:
        WARNING: file compiler/simplCore/CSE.lhs line 326
        extendCSEnv: long list, length 18
      from a compiler built with -DDEBUG
      21eeb926
  25. 12 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      A radical overhaul of the coercion infrastucture · cd0e2c0c
      simonpj@microsoft.com authored
      * Core Lint now does full checking of kinds and coercion terms
        which picks up kind errors in coercions that were previously
        simply not checked for
      
      * Coercion.lhs now provides optCoercion which optimises coercion
        terms.  It implements all of Dimitrios's rules
      
      * The constructors for coercion terms now make no attempt to be
        "smart"; instead we rely solely on the coercion optimiser
      
      * CoercionTyCons in TyCon.lhs always had a "custom" kinding rule
        (the coKindFun field of CoercionTyCon) but its type was not 
        clever enough to do both 
           (a) *figure out the result kind*, assuming the whole thing
               is well-kinded in the first place
           (b) *check* the kinds of everything, failing gracefully if
               they aren't right. 
        We need (b) for the new CoreLint stuff. The field now has type
              CoTyConKindChecker
        which does the job nicely.
      cd0e2c0c
  26. 08 Nov, 2009 1 commit
  27. 06 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up coercions, and implement csel1, csel2, cselR · bcadca67
      simonpj@microsoft.com authored
      In preparation for implementing the PushC rule for coercion-swizzling
      in the Simplifier, I had to inmplement the three new decomposition
      operators for coercions, which I've called csel1, csel2, and cselR.
      
           co :: ((s1~t1) => r1) ~ ((s2~t2) => r2)
           ---------------------------------------
                    csel1 co :: s1~s2
      
      and similarly csel2, cselR.
      
      On the way I fixed the coercionKind function for types of form
                (s1~t2) => r2
      which currently are expressed as a forall type.  
      
      And I refactored quite a bit to help myself understand what is
      going on.
      bcadca67
  28. 30 Oct, 2009 1 commit
  29. 28 Oct, 2009 1 commit
  30. 26 Oct, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Add a coercion optimiser, to reduce the size of coercion terms · 48196c3c
      simonpj@microsoft.com authored
      Coercion terms can get big (see Trac #2859 for example), so this
      patch puts the infrastructure in place to optimise them:
      
        * Adds Coercion.optCoercion :: Coercion -> Coercion
      
        * Calls optCoercion in Simplify.lhs
      
      The optimiser doesn't work right at the moment, so it is 
      commented out, but Tom is going to work on it.
      48196c3c
  31. 06 Jul, 2009 1 commit
  32. 15 Mar, 2009 1 commit
  33. 13 Jan, 2009 1 commit
  34. 29 Oct, 2008 1 commit