1. 02 Mar, 2015 1 commit
  2. 10 Feb, 2015 1 commit
  3. 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
  4. 01 Dec, 2014 1 commit
  5. 28 Nov, 2014 1 commit
  6. 06 Nov, 2014 1 commit
  7. 31 Oct, 2014 1 commit
  8. 19 Sep, 2014 1 commit
    • Simon Peyton Jones's avatar
      Clean up Coercible handling, and interaction of data families with newtypes · 0aaf812e
      Simon Peyton Jones authored
      This patch fixes Trac #9580, in which the Coercible machinery succeeded
      even though the relevant data constructor was not in scope.
      
      As usual I got dragged into a raft of refactoring changes,
      all for the better.
      
      * Delete TcEvidence.coercionToTcCoercion (now unused)
      
      * Move instNewTyConTF_maybe, instNewTyCon_maybe to FamInst,
        and rename them to tcInstNewTyConTF_maybe, tcInstNewTyCon
        (They both return TcCoercions.)
      
      * tcInstNewTyConTF_maybe also gets more convenient type,
        which improves TcInteract.getCoercibleInst
      
      * Define FamInst.tcLookupDataFamInst, and use it in TcDeriv,
        (as well as in tcInstNewTyConTF_maybe)
      
      * Improve error report for Coercible errors, when data familes
        are involved  Another use of tcLookupDataFamInst
      
      * In TcExpr.tcTagToEnum, use tcLookupDataFamInst to replace
        local hacky code
      
      * Fix Coercion.instNewTyCon_maybe and Type.newTyConInstRhs to deal
        with eta-reduced newtypes, using
        (new) Type.unwrapNewTyConEtad_maybe and (new) Type.applyTysX
      
      Some small refactoring of TcSMonad.matchFam.
      0aaf812e
  9. 17 Sep, 2014 1 commit
  10. 27 Jun, 2014 2 commits
  11. 20 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Tidy up the printing of single-predicate contexts · 0ceb84e9
      Simon Peyton Jones authored
      This covers things like
         Eq a => blah   and   (?x::Int) => blah
      where there is just one predicate. Previously we used an ad-hoc
      test to decide whether to parenthesise it, but acutally there is
      a much simpler solution: just use the existing precedence mechamism.
      
      This applies both to Type and HsType.
      0ceb84e9
  12. 11 Jun, 2014 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #9062. · e79e2c39
      eir@cis.upenn.edu authored
      Removed (pprEqPred (coercionKind co)) in favor of
      (pprType (coercionType co)).
      
      Also had to make "~R#" a *symbolic* identifier and BuiltInSyntax
      to squelch prefix notation and module prefixes in output. These
      changes are both sensible independent of #9062.
      e79e2c39
  13. 23 May, 2014 2 commits
  14. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  15. 06 May, 2014 1 commit
    • Simon Peyton Jones's avatar
      Modularise pretty-printing for foralls · 3c3ce829
      Simon Peyton Jones authored
      See TypeRep.pprUserForAll.  This just makes forall-printing a bit more
      consistent.  In particular, I wasn't seeing the kind foralls when
      displaying a CoAxiom or CoAxBranch
      
      The output on T7939 is just possible a bit too verbose now, but even if so
      that's an error in the right direction.
      3c3ce829
  16. 17 Mar, 2014 1 commit
  17. 01 Feb, 2014 1 commit
  18. 27 Nov, 2013 2 commits
    • Joachim Breitner's avatar
      Get rid of EvCoercible · 808ded9c
      Joachim Breitner authored
      and use EvCoercion to describe the evidence for Coercible instances.
      808ded9c
    • Joachim Breitner's avatar
      Roleify TcCoercion · 9d643cf6
      Joachim Breitner authored
      Previously, TcCoercion were only used to represent boxed Nominal
      coercions. In order to also talk about boxed Representational coercions
      in the type checker, we add Roles to TcCoercion. Again, we closely
      mirror Coercion.
      
      The roles are verified by a few assertions, and at the latest after
      conversion to Coercion. I have put my trust in the comprehensiveness of
      the testsuite here, but any role error after desugaring popping up now
      might be caused by this refactoring.
      9d643cf6
  19. 22 Nov, 2013 2 commits
    • Simon Peyton Jones's avatar
      Replace (State# RealWorld) with Void# where we just want a 0-bit value · f4384647
      Simon Peyton Jones authored
      We were re-using the super-magical "state token" type (which has
      VoidRep and is zero bits wide) for situations in which we simply want
      to lambda-abstract over a zero-bit argument. For example, join points:
      
         case (case x of { True -> e1; False -> e2 }) of
            Red  -> f1
            Blue -> True
      
      ==>
      
        let $j1 = \voidArg::Void# -> f1
        in
        case x of
          True -> case e1 of
                    Red -> $j1 void
                    Blue -> True
          False -> case e2 of
                    Red -> $j1 void
                    Blue -> True
      
      This patch introduces
      
         * The new primitive type GHC.Prim.Void#, with PrimRep = VoidRep
      
         * A new global Id GHC.Prim.voidPrimId :: Void#.
           This has no binding because the code generator drops it,
           but is used as an argument (eg in the call of $j1)
      
         * A new local Id, MkId.voidArgId, which can be lambda-bound
           when you need to lambda-abstract over it.
      
      and uses them throughout.
      
      Now the State# thing is used only when we need state!
      f4384647
    • Simon Peyton Jones's avatar
      Fix type-equality in the type checker (fixes Trac #8553) · 985663ea
      Simon Peyton Jones authored
      For horrible reasons (Note [Comparison with OpenTypeKind] in Type), the
      function Type.eqType currently equates OOpenKind with *.  This may or may
      not be a good idea (it's certainly a revolting one) but it DOES NOT WORK
      in the type checker, which *does* need to distinguish OpenKind and *.
      
      Rather than solve the underlying problem (I have some ideas) I just
      introduced a new, and very short, simple, straightforward function
      TcType.tcEqType to do the job.
      985663ea
  20. 20 Nov, 2013 1 commit
  21. 12 Oct, 2013 1 commit
  22. 01 Oct, 2013 1 commit
  23. 20 Sep, 2013 1 commit
  24. 13 Sep, 2013 1 commit
  25. 08 Sep, 2013 1 commit
  26. 02 Sep, 2013 1 commit
    • Simon Peyton Jones's avatar
      Make Specialise close over kind variables (fixes Trac #8196) · 8d7dd547
      Simon Peyton Jones authored
      This is a lingering bug from the introduction of polymorphic kinds.
      In the specialiser we were specialising over a type, but failing
      to specialise over the kinds it mentions.
      
      The fix is simple: add a call to closeOverKinds.
      
      Most of the patch is to add closeOverKinds, and to use it in a few
      other places where we are doing essentially the same thing.
      8d7dd547
  27. 02 Aug, 2013 1 commit
  28. 11 Jun, 2013 1 commit
  29. 10 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Fix egregious typo in cmpTypeX · 0239d783
      Simon Peyton Jones authored
      Reported in Trac #7272.  "tv1" should be "tv2"!
      
      However, things weren't as simple as they sound, because
      treating (x:Open) as different from (x:*) gave rise to
      new failures; see Note [Comparison with OpenTypeKind] in Type.
      
      My hacky solution is to treat OpenKind as equal to * and #,
      at least in Core etc.  Hence the faff in Type.cmpTc.
      
      I do not like this.  But it seems like another messy consequence
      of including sub-kinding.  Sigh.
      0239d783
  30. 06 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Add TyCon.checkRecTc, and use in in typeArity · a1a67b58
      Simon Peyton Jones authored
      This just formalises an abstraction we've been using anyway,
      namely to expand "recursive" TyCons until we see them twice.
      We weren't doing this in typeArity, and that inconsistency
      was leading to a subsequent ASSERT failure, when compiling
      Stream.hs, which has a newtype like this
      
         newtype Stream m a b = Stream (m (Either b (a, Stream m a b)))
      a1a67b58
  31. 30 May, 2013 1 commit
  32. 03 May, 2013 1 commit
    • Simon Peyton Jones's avatar
      Make isPredTy not use typeKind · f3472f55
      Simon Peyton Jones authored
      The pretty-printer uses isPredTy to decide whether to use "=>" or "->",
      and typeKind crashes on ill-kinded types. But it's really unhelpful for
      the pretty-printer to crash on an ill-kinded type, because then you can't
      see it!
      f3472f55
  33. 06 Apr, 2013 1 commit
  34. 15 Feb, 2013 1 commit
  35. 28 Jan, 2013 1 commit
    • Simon Peyton Jones's avatar
      Pure refactoring · f1fa6eb2
      Simon Peyton Jones authored
      * Move tidyType and friends from TcType to TypeRep
        (It was always wrong to have it in TcType.)
      
      * Move mkCoAxBranch and friends from FamInst to Coercion
      
      * Move pprCoAxBranch and friends from FamInstEnv to Coercion
      
      No change in functionality, though there might be a little
      wibble in error message output, because I combined two different
      functions both called pprCoAxBranch!
      f1fa6eb2
  36. 25 Jan, 2013 1 commit