1. 02 Apr, 2012 1 commit
  2. 30 Mar, 2012 1 commit
  3. 29 Mar, 2012 5 commits
  4. 28 Mar, 2012 2 commits
  5. 02 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Hurrah! This major commit adds support for scoped kind variables, · 3bf54e78
      Simon Peyton Jones authored
      which (finally) fills out the functionality of polymorphic kinds.
      It also fixes numerous bugs.
      Main changes are:
      Renaming stuff
      * New type in HsTypes:
           data HsBndrSig sig = HsBSig sig [Name]
        which is used for type signatures in patterns, and kind signatures
        in types.  So when you say
             f (x :: [a]) = x ++ x
             data T (f :: k -> *) (x :: *) = MkT (f x)
        the signatures in both cases are a HsBndrSig.
      * The [Name] in HsBndrSig records the variables bound by the
        pattern, that is 'a' in the first example, 'k' in the second,
        and nothing in the third.  The renamer initialises the field.
      * As a result I was able to get rid of
           RnHsSyn.extractHsTyNames :: LHsType Name -> NameSet
        and its friends altogether.  Deleted the entire module!
        This led to some knock-on refactoring; in particular the
        type renamer now returns the free variables just like the
        term renamer.
      Kind-checking types: mainly TcHsType
      A major change is that instead of kind-checking types in two
      passes, we now do one. Under the old scheme, the first pass did
      kind-checking and (hackily) annotated the HsType with the
      inferred kinds; and the second pass desugared the HsType to a
      Type.  But now that we have kind variables inside types, the
      first pass (TcHsType.tc_hs_type) can go straight to Type, and
      zonking will squeeze out any kind unification variables later.
      This is much nicer, but it was much more fiddly than I had expected.
      The nastiest corner is this: it's very important that tc_hs_type
      uses lazy constructors to build the returned type. See
      Note [Zonking inside the knot] in TcHsType.
      Type-checking type and class declarations: mainly TcTyClsDecls
      I did tons of refactoring in TcTyClsDecls.  Simpler and nicer now.
      Typechecking bindings: mainly TcBinds
      I rejigged (yet again) the handling of type signatures in TcBinds.
      It's a bit simpler now.  The main change is that tcTySigs goes
      right through to a TcSigInfo in one step; previously it was split
      into two, part here and part later.
      Unsafe coercions
      Usually equality coercions have exactly the same kind on both
      sides.  But we do allow an *unsafe* coercion between Int# and Bool,
      say, used in
          case error Bool "flah" of { True -> 3#; False -> 0# }
          (error Bool "flah") |> unsafeCoerce Bool Int#
      So what is the instantiation of (~#) here?
         unsafeCoerce Bool Int# :: (~#) ??? Bool Int#
      I'm using OpenKind here for now, but it's un-satisfying that
      the lhs and rhs of the ~ don't have precisely the same kind.
      More minor
      * HsDecl.TySynonym has its free variables attached, which makes
        the cycle computation in TcTyDecls.mkSynEdges easier.
      * Fixed a nasty reversed-comparison bug in FamInstEnv:
        @@ -490,7 +490,7 @@ lookup_fam_inst_env' match_fun one_sided ie fam tys
           n_tys = length tys
           extra_tys = drop arity tys
           (match_tys, add_extra_tys)
      -       | arity > n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
      +       | arity < n_tys = (take arity tys, \res_tys -> res_tys ++ extra_tys)
              | otherwise     = (tys,            \res_tys -> res_tys)
  6. 17 Feb, 2012 1 commit
  7. 16 Feb, 2012 1 commit
  8. 25 Jan, 2012 1 commit
    • Iavor S. Diatchki's avatar
      Add support for type-level "strings". · 5851f847
      Iavor S. Diatchki authored
      These are types that look like "this" and "that".
      They are of kind `Symbol`, defined in module `GHC.TypeLits`.
      For each type-level symbol `X`, we have a singleton type, `TSymbol X`.
      The value of the singleton type can be named with the overloaded
      constant `tSymbol`.  Here is an example:
      tSymbol :: TSymbol "Hello"
  9. 17 Jan, 2012 1 commit
  10. 12 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Implememt -fdefer-type-errors (Trac #5624) · 5508ada4
      Simon Peyton Jones authored
      This patch implements the idea of deferring (most) type errors to
      runtime, instead emitting only a warning at compile time.  The
      basic idea is very simple:
       * The on-the-fly unifier in TcUnify never fails; instead if it
         gets stuck it emits a constraint.
       * The constraint solver tries to solve the constraints (and is
         entirely unchanged, hooray).
       * The remaining, unsolved constraints (if any) are passed to
         TcErrors.reportUnsolved.  With -fdefer-type-errors, instead of
         emitting an error message, TcErrors emits a warning, AND emits
         a binding for the constraint witness, binding it
         to (error "the error message"), via the new form of evidence
         TcEvidence.EvDelayedError.  So, when the program is run,
         when (and only when) that witness is needed, the program will
         crash with the exact same error message that would have been
         given at compile time.
      Simple really.  But, needless to say, the exercise forced me
      into some major refactoring.
       * TcErrors is almost entirely rewritten
       * EvVarX and WantedEvVar have gone away entirely
       * ErrUtils is changed a bit:
           * New Severity field in ErrMsg
           * Renamed the type Message to MsgDoc (this change
             touches a lot of files trivially)
       * One minor change is that in the constraint solver we try
         NOT to combine insoluble constraints, like Int~Bool, else
         all such type errors get combined together and result in
         only one error message!
       * I moved some definitions from TcSMonad to TcRnTypes,
         where they seem to belong more
  11. 07 Jan, 2012 1 commit
  12. 03 Jan, 2012 1 commit
    • Simon Peyton Jones's avatar
      Major refactoring of CoAxioms · 98a642cf
      Simon Peyton Jones authored
      This patch should have no user-visible effect.  It implements a
      significant internal refactoring of the way that FC axioms are
      handled.  The ultimate goal is to put us in a position to implement
      "pattern-matching axioms".  But the changes here are only does
      refactoring; there is no change in functionality.
       * We now treat data/type family instance declarations very,
         very similarly to types class instance declarations:
         - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with
           FamInstEnv.FamInst.  This change does affect the GHC API, but
           for the better I think.
         - Previously, each family type/data instance declaration gave rise
           to a *TyCon*; typechecking a type/data instance decl produced
           that TyCon.  Now, each type/data instance gives rise to
           a *FamInst*, by direct analogy with each class instance
           declaration giving rise to a ClsInst.
         - Just as each ClsInst contains its evidence, a DFunId, so each FamInst
           contains its evidence, a CoAxiom.  See Note [FamInsts and CoAxioms]
           in FamInstEnv.  The CoAxiom is a System-FC thing, and can relate any
           two types, whereas the FamInst relates directly to the Haskell source
           language construct, and always has a function (F tys) on the LHS.
         - Just as a DFunId has its own declaration in an interface file, so now
           do CoAxioms (see IfaceSyn.IfaceAxiom).
         These changes give rise to almost all the refactoring.
       * We used to have a hack whereby a type family instance produced a dummy
         type synonym, thus
            type instance F Int = Bool -> Bool
         translated to
            axiom FInt :: F Int ~ R:FInt
            type R:FInt = Bool -> Bool
         This was always a hack, and now it's gone.  Instead the type instance
         declaration produces a FamInst, whose axiom has kind
            axiom FInt :: F Int ~ Bool -> Bool
         just as you'd expect.
       * Newtypes are done just as before; they generate a CoAxiom. These
         CoAxioms are "implicit" (do not generate an IfaceAxiom declaration),
         unlike the ones coming from family instance declarations.  See
         Note [Implicit axioms] in TyCon
      On the whole the code gets significantly nicer.  There were consequential
      tidy-ups in the vectoriser, but I think I got them right.
  13. 30 Dec, 2011 1 commit
    • Iavor S. Diatchki's avatar
      Add the built-in instances for class NatI. · 4715b871
      Iavor S. Diatchki authored
      Note 1: For the moment, we provide instances only for numbers that
      fit in a Word.  The reason is a quite mundane:  to generate evidence
      for arbitrary integers we need to generate integer literals.
      In the core syntax this is a monadic operation but the function that
      generates the core for evidence is pure.  It would not be hard to monadify
      it but requires changes to a bunch of other functions so I thought it
      is better left for a separate change.
      Note 2: The evidence that we generate for a NatI is just a word.
      Technically, we should be generate a word with two coercions: one to
      turn it into a NatS and another to turn that into a NatI.  Operationally,
      these do not do anything, but it would be better to fix this.  I didn't
      do it yet because I need to look up how to make these coercions.
  14. 22 Dec, 2011 1 commit
  15. 15 Dec, 2011 1 commit
  16. 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.
  17. 29 Nov, 2011 1 commit
  18. 28 Nov, 2011 3 commits
    • dimitris's avatar
      isReflCo no longer reliable for detection of type identity. · e5449309
      dimitris authored
      isReflCo is no longer reliable for detection of no-rewriting/flattening
      since we are using cached reflexivity solved goals. Introduced a boolean
      flag in the flattener for this purpose, instead.
    • 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.
    • dimitris's avatar
      This patch includes: · f3183d9a
      dimitris authored
      0) Typo in panic message.
      1) prioritization of equalities over family equalities in the worklists.
      2) rewriting of inert substitutions and solveds on-the-spot instead of
         kicking them out in the inerts. This required a monadic map over
         substitutions hence the modifications in UniqFM.
      3) Just comments and removing stale commented code.
      4) Useful SCC for simplifyInfer.
      5) Making CoreStats outputable.
  19. 21 Nov, 2011 1 commit
    • dreixel's avatar
      Rename ? to OpenKind and ?? to ArgKind · 18c7aea0
      dreixel authored
      The previous names were not informative at all, and now we have
      named kinds like Constraint and datatype promotion to kind, so
      we might as well name these too.
      I tried to update some comments to the new names, but certainly
      many references to the old names remain.
  20. 16 Nov, 2011 1 commit
  21. 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
  22. 04 Nov, 2011 1 commit
  23. 10 Sep, 2011 1 commit
  24. 06 Sep, 2011 1 commit
    • 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)
  25. 24 Aug, 2011 1 commit
  26. 03 Aug, 2011 1 commit
  27. 02 Aug, 2011 1 commit
  28. 31 Jul, 2011 1 commit
  29. 29 Jul, 2011 1 commit
  30. 22 Jun, 2011 1 commit
    • Simon Peyton Jones's avatar
      Remove "silent superclass parameters" · a9d48fd9
      Simon Peyton Jones authored
      We introduced silent superclass parameters as a way to avoid
      superclass loops, but we now solve that problem a different
      way ("derived" superclass constraints carry no evidence). So
      they aren't needed any more.
      Apart from being a needless complication, they broke DoCon.
      Admittedly in a very obscure way, but still the result is
      hard to explain. To see the details see Trac #5051, with
      test case typecheck/should_compile/T5051.  (The test is
      nice and small!)
  31. 08 Jun, 2011 1 commit
    • dimitris's avatar
      Reorganized functional dependency reactions once more: · 107715b3
      dimitris authored
       1) generating Derived FDs as happens for equality superclasses
       2) Kept the optimization of immediately discharging items
          if fundeps cause a match
       3) Restructured top-reactions and interactions with inerts to
          behave similarly to each other.
      In particular, (1) fixes ticket #5236.
  32. 17 May, 2011 1 commit
    • dimitris's avatar
      Introducing: · 9591547f
      dimitris authored
         1) Postponing the application of instances when there
            is a possibility of a given matching. With the addition
            of prioritizing equalities this fixes #5002 and #4981.
         2) Implemented caching of flattening in constraint
            simplification. This improves efficiency (fixes #5030)
         3) Simplified pushing of unsolved wanteds
            (now pushing only equalities) inside implications.
  33. 02 May, 2011 1 commit