1. 10 Jul, 2012 1 commit
  2. 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
      5a8ac0f8
  3. 12 Jun, 2012 1 commit
  4. 25 May, 2012 1 commit
  5. 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.
      dd7522c3
  6. 01 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Tidy up a remaining glitch in unification · 67c793a3
      Simon Peyton Jones authored
      There was one place, in type checking parallel list comprehensions
      where we were unifying types, but had no convenient way to use the
      resulting coercion; instead we just checked that it was Refl.  This
      was Wrong Wrong; it might fail unpredicably in a GADT-like situation,
      and it led to extra error-generation code used only in this one place.
      
      This patch tidies it all up, by moving the 'return' method from the
      *comprehension* to the ParStmtBlock. The latter is a new data type,
      now used for each sub-chunk of a parallel list comprehension.
      
      Because of the data type change, quite a few modules are touched,
      but only in a fairly trivial way. The real changes are in TcMatches
      (and corresponding desugaring); plus deleting code from TcUnify.
      
      This patch also fixes the pretty-printing bug in Trac #6060
      67c793a3
  7. 27 Apr, 2012 1 commit
  8. 29 Mar, 2012 1 commit
  9. 28 Mar, 2012 1 commit
    • dimitris's avatar
      Midstream check-in on · cc2d2e1d
      dimitris authored
         (i) Replaced a lot of clunky and fragile EvVar handling code with
             a more uniform ``flavor transformer'' API in the canonicalizer
             and the interaction solver. Now EvVars are just fields inside
             the CtFlavors.
         (ii) Significantly simplified our caching story
      This patch does not validate yet and more refactoring is on the way.
      cc2d2e1d
  10. 09 Mar, 2012 1 commit
  11. 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
        or
             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)
      3bf54e78
  12. 17 Feb, 2012 1 commit
  13. 16 Feb, 2012 1 commit
  14. 19 Jan, 2012 1 commit
  15. 13 Jan, 2012 1 commit
  16. 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
      5508ada4
  17. 22 Dec, 2011 1 commit
  18. 19 Dec, 2011 1 commit
  19. 16 Nov, 2011 1 commit
  20. 04 Nov, 2011 1 commit
  21. 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)
      9729fe7c
  22. 16 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Major improvement to pattern bindings · 49dbe605
      Simon Peyton Jones authored
      This patch makes a number of related improvements
      
      a) Implements the Haskell Prime semantics for pattern bindings
         (Trac #2357).  That is, a pattern binding p = e is typed
         just as if it had been written
              t = e
              f = case t of p -> f
              g = case t of p -> g
              ... etc ...
         where f,g are the variables bound by p. In paricular it's
         ok to say
            (f,g) = (\x -> x, \y -> True)
         and f and g will get propertly inferred types
            f :: a -> a
            g :: a -> Int
      
      b) Eliminates the MonoPatBinds flag altogether.  (For the moment
         it is deprecated and has no effect.)  Pattern bindings are now
         generalised as per (a).  Fixes Trac #2187 and #4940, in the
         way the users wanted!
      
      c) Improves the OutsideIn algorithm generalisation decision.
         Given a definition without a type signature (implying "infer
         the type"), the published algorithm rule is this:
            - generalise *top-level* functions, and
            - do not generalise *nested* functions
         The new rule is
            - generalise a binding whose free variables have
              Guaranteed Closed Types
            - do not generalise other bindings
      
         Generally, a top-level let-bound function has a Guaranteed
         Closed Type, and so does a nested function whose free vaiables
         are top-level functions, and so on. (However a top-level
         function that is bitten by the Monomorphism Restriction does
         not have a GCT.)
      
         Example:
           f x = let { foo y = y } in ...
         Here 'foo' has no free variables, so it is generalised despite
         being nested.
      
      d) When inferring a type f :: ty for a definition f = e, check that
         the compiler would accept f :: ty as a type signature for that
         same definition.  The type is rejected precisely when the type
         is ambiguous.
      
         Example:
            class Wob a b where
              to :: a -> b
              from :: b -> a
      
            foo x = [x, to (from x)]
         GHC 7.0 would infer the ambiguous type
            foo :: forall a b. Wob a b => b -> [b]
         but that type would give an error whenever it is called; and
         GHC 7.0 would reject that signature if given by the
         programmer.  The new type checker rejects it up front.
      
         Similarly, with the advent of type families, ambiguous types are
         easy to write by mistake.  See Trac #1897 and linked tickets for
         many examples.  Eg
            type family F a :: *
            f ::: F a -> Int
            f x = 3
         This is rejected because (F a ~ F b) does not imply a~b.  Previously
         GHC would *infer* the above type for f, but was unable to check it.
         Now even the inferred type is rejected -- correctly.
      
      The main implemenation mechanism is to generalise the abe_wrap
      field of ABExport (in HsBinds), from [TyVar] to HsWrapper. This
      beautiful generalisation turned out to make everything work nicely
      with minimal programming effort.  All the work was fiddling around
      the edges; the core change was easy!
      49dbe605
  23. 03 Aug, 2011 1 commit
  24. 23 Jul, 2011 1 commit
    • Simon Peyton Jones's avatar
      Reject bad 'deriving' directives (fixes Trac #5287) · 49861e71
      Simon Peyton Jones authored
      The 'deriving' mechanism that infers the context for
      an instance declarations was going into a loop, as a
      result of an instance like
             instance C a b => D [a]
      where the 'b' isn't mentioned in the head.
      
      This patch identifies those cases.  I also needed to make
      TcErrors generate a suitable error message.  On the way
      I improved the reporting of "ambiguous" variables;
      for example arrowfail001 now generates a better message.
      49861e71
  25. 18 Jul, 2011 1 commit
  26. 15 Jul, 2011 1 commit
  27. 14 Jul, 2011 1 commit
    • Ian Lynagh's avatar
      Separate the warning flags into their own datatype · 493ea4ab
      Ian Lynagh authored
      The -w flag wasn't turning off a few warnings (Opt_WarnMissingImportList,
      Opt_WarnMissingLocalSigs, Opt_WarnIdentities). Rather than just adding
      them, I've separated the Opt_Warn* contructors off into their own type,
      so -w now just sets the list of warning flags to [].
      493ea4ab
  28. 30 Jun, 2011 1 commit
  29. 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!)
      a9d48fd9
  30. 18 Jun, 2011 2 commits
  31. 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.
      9591547f
  32. 20 Apr, 2011 2 commits
  33. 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
  34. 16 Jan, 2011 1 commit
    • Iavor S. Diatchki's avatar
      Add basic support for number type literals. · 9cbc204d
      Iavor S. Diatchki authored
      We add a new kind, Nat, inhabited by a family of types,
      one for each natural number:
      
      0, 1, 2 .. :: Nat
      
      In terms of GHC's sub-kind relation, Nat is only a sub-kind of itself.
      
      The numeric types are empty because there are no primitives of these
      types, and the kind "Nat" is not related to *, the kind of types which
      can be defined in Haskell programs.
      9cbc204d
  35. 12 Jan, 2011 1 commit
    • simonpj@microsoft.com's avatar
      Major refactoring of the type inference engine · 27310213
      simonpj@microsoft.com authored
      This patch embodies many, many changes to the contraint solver, which
      make it simpler, more robust, and more beautiful.  But it has taken
      me ages to get right. The forcing issue was some obscure programs
      involving recursive dictionaries, but these eventually led to a
      massive refactoring sweep.
      
      Main changes are:
       * No more "frozen errors" in the monad.  Instead "insoluble
         constraints" are now part of the WantedConstraints type.
      
       * The WantedConstraint type is a product of bags, instead of (as
         before) a bag of sums.  This eliminates a good deal of tagging and
         untagging.
      
       * This same WantedConstraints data type is used
           - As the way that constraints are gathered
           - As a field of an implication constraint
           - As both argument and result of solveWanted
           - As the argument to reportUnsolved
      
       * We do not generate any evidence for Derived constraints. They are
         purely there to allow "impovement" by unifying unification
         variables.
      
       * In consequence, nothing is ever *rewritten* by a Derived
         constraint.  This removes, by construction, all the horrible
         potential recursive-dictionary loops that were making us tear our
         hair out.  No more isGoodRecEv search either. Hurrah!
      
       * We add the superclass Derived constraints during canonicalisation,
         after checking for duplicates.  So fewer superclass constraints
         are generated than before.
      
       * Skolem tc-tyvars no longer carry SkolemInfo.  Instead, the
         SkolemInfo lives in the GivenLoc of the Implication, where it
         can be tidied, zonked, and substituted nicely.  This alone is
         a major improvement.
      
       * Tidying is improved, so that we tend to get t1, t2, t3, rather
         than t1, t11, t111, etc
      
         Moreover, unification variables are always printed with a digit
         (thus a0, a1, etc), so that plain 'a' is available for a skolem
         arising from a type signature etc. In this way,
           (a) We quietly say which variables are unification variables,
               for those who know and care
           (b) Types tend to get printed as the user expects.  If he writes
                   f :: a -> a
                   f = ...blah...
               then types involving 'a' get printed with 'a', rather than
               some tidied variant.
      
       * There are significant improvements in error messages, notably
         in the "Cannot deduce X from Y" messages.
      27310213
  36. 13 Dec, 2010 1 commit
    • simonpj@microsoft.com's avatar
      Fix recursive superclasses (again). Fixes Trac #4809. · a3bab050
      simonpj@microsoft.com authored
      This patch finally deals with the super-delicate question of
      superclases in possibly-recursive dictionaries.  The key idea
      is the DFun Superclass Invariant (see TcInstDcls):
      
           In the body of a DFun, every superclass argument to the
           returned dictionary is
             either   * one of the arguments of the DFun,
             or       * constant, bound at top level
      
      To establish the invariant, we add new "silent" superclass
      argument(s) to each dfun, so that the dfun does not do superclass
      selection internally.  There's a bit of hoo-ha to make sure that
      we don't print those silent arguments in error messages; a knock
      on effect was a change in interface-file format.
      
      A second change is that instead of the complex and fragile
      "self dictionary binding" in TcInstDcls and TcClassDcl,
      using the same mechanism for existential pattern bindings.
      See Note [Subtle interaction of recursion and overlap] in TcInstDcls
      and Note [Binding when looking up instances] in InstEnv.
      
      Main notes are here:
      
        * Note [Silent Superclass Arguments] in TcInstDcls,
          including the DFun Superclass Invariant
      
      Main code changes are:
      
        * The code for MkId.mkDictFunId and mkDictFunTy
      
        * DFunUnfoldings get a little more complicated;
          their arguments are a new type DFunArg (in CoreSyn)
      
        * No "self" argument in tcInstanceMethod
        * No special tcSimplifySuperClasss
        * No "dependents" argument to EvDFunApp
      
      IMPORTANT
         It turns out that it's quite tricky to generate the right
         DFunUnfolding for a specialised dfun, when you use SPECIALISE
         INSTANCE.  For now I've just commented it out (in DsBinds) but
         that'll lose some optimisation, and I need to get back to
         this.
      a3bab050
  37. 18 Nov, 2010 1 commit
  38. 15 Nov, 2010 1 commit