1. 12 Dec, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Rewrite `Coercible` solver · 0cc47eb9
      eir@cis.upenn.edu authored
      Summary:
      This is a rewrite of the algorithm to solve for Coercible "instances".
      
      A preliminary form of these ideas is at
      https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver
      
      The basic idea here is that the `EqPred` constructor of `PredTree`
      now is parameterised by a new type `EqRel` (where
      `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can
      now talk about nominal equality (the usual case) or representational
      equality (the `Coercible` case).
      
      This is a change from the previous
      behavior where `Coercible` was just considered a regular class with
      a special case in `matchClassInst`.
      
      Because of this change, representational equalities are now
      canonicalized just like nominal ones, allowing more equalities
      to be solved -- in particular, the case at the top of #9117.
      
      A knock-on effect is that the flattener must be aware of the
      choice of equality relation, because the inert set now stores
      both representational inert equalities alongside the nominal
      inert equalities. Of course, we can use representational equalities
      to rewrite only within another representational equality --
      thus the parameterization of the flattener.
      
      A nice side effect of this change is that I've introduced a new
      type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness
      in the flattener.
      
      This commit includes some refactoring as discussed on D546.
      It also removes the ability of Deriveds to rewrite Deriveds.
      
      This fixes bugs #9117 and #8984.
      
      Reviewers: simonpj, austin, nomeata
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D546
      
      GHC Trac Issues: #9117, #8984
      0cc47eb9
  2. 11 Dec, 2014 2 commits
    • Simon Peyton Jones's avatar
      Fix an obscure but terrible bug in the simplifier (Trac #9567) · b8392ae7
      Simon Peyton Jones authored
      The issue was that contInputType simply gave the wrong answer
      for type applications.
      
      There was no way to fix contInputType; it just didn't have enough
      information.  So I did this:
      
      * Split the ApplyTo constructor of SimplUtils.SimplCont into
            ApplyToVal
            ApplyToTy
        I used record syntax for them; we should do this for some
        of the other constructors too.
      
      * The latter carries a sc_hole_ty, which is the type of the
        continuation's "hole"
      
      * Maintaining this type meant that I had do to something
        similar for SimplUtils.ArgSpec.
      
      * I renamed contInputType to contHoleType for consistency.
      
      * I did a bit of refactoring around the call to tryRules
        in Simplify, which was jolly confusing before.
      
      The resulting code is quite nice now.  And it has the additional
      merit that it works.
      
      The tests are simply tc124 and T7891 with -O enabled.
      b8392ae7
    • Simon Peyton Jones's avatar
      White space wibble only · d45edfb3
      Simon Peyton Jones authored
      d45edfb3
  3. 10 Dec, 2014 8 commits
  4. 08 Dec, 2014 7 commits
  5. 07 Dec, 2014 1 commit
  6. 06 Dec, 2014 3 commits
  7. 05 Dec, 2014 1 commit
  8. 04 Dec, 2014 2 commits
  9. 03 Dec, 2014 15 commits