1. 08 Jan, 2013 2 commits
    • Simon Peyton Jones's avatar
      Add missing import · 0a24be00
      Simon Peyton Jones authored
      0a24be00
    • Simon Peyton Jones's avatar
      Re-engineer the ambiguity test for user type signatures · 97db0edc
      Simon Peyton Jones authored
      Two main changes. First, re-engineer the ambiguity test.  Previously
      TcMType.checkAmbiguity used a rather syntactic test to detect some
      types that are certainly ambiguous.  But a much easier test is available,
      and it is used for inferred types in TcBinds. Namely
          <type> is ambiguous
      iff
         <type> `TcUnify.isSubType` <type>
      fails to hold, where "isSubType" means "is provably more polymorphic than".
      Example:
            C a => Int
      is ambiguous, because isSubType instantiates the (C a => Int)
      to (C alpha => Int) and then tries to deduce (C alpha) from (C a). This is
      Martin Sulzmann's definition of ambiguity.  (Defn 10 of "Understanding
      functional dependencies via constraint handling rules", JFP.)
      
      This change is neat, reduces code, and correctly rejects more programs.
      However is *is* just possible to have a useful program that would be
      rejected. For example
                class C a b
                f :: C Int b => Int -> Int
      Here 'f' would be rejected as having an ambiguous type. But it is
      just possible that, at a *call* site there might be an instance
      declaration  instance C Int b, which does not constrain 'b' at all.
      This is pretty strange -- why is 'b' overloaded at all? -- but it's
      possible, so I also added a flag -XAllowAmbiguousTypes that simply
      removes the ambiguity check.  Let's see if anyone cares.  Meanwhile
      the earlier error report will be useful for everyone else.
      
      A handful of regression tests had to be adjusted as a result, because
      they used ambiguous types, somewhat accidentally.
      
      Second, split TcMType (already too large) into two
      
        * TcMType: a low-level module dealing with monadic operations like
          zonking, creating new evidence variables, etc
      
        * TcValidity: a brand-new higher-level module dealing with
          validity checking for types: checkValidType, checkValidInstance,
          checkFamInstPats etc
      
      Apart from the fact that TcMType was too big, this allows TcValidity
      to import TcUnify(tcSubType) without causing a loop.
      97db0edc
  2. 05 Jan, 2013 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor invariants for FamInsts. · 5765248b
      eir@cis.upenn.edu authored
      This commit mirrors work done in the commit for ClsInsts, 5efe9b...
      
      Specifically:
      - All FamInsts have *fresh* type variables. So, no more freshness work
      in addLocalFamInst
      
      Also:
      - Some pretty-printing code around FamInsts was cleaned up a bit
      This caused location information to be added to CoAxioms and index
      information to be added to FamInstBranches.
      5765248b
  3. 02 Jan, 2013 3 commits
  4. 01 Jan, 2013 1 commit
  5. 31 Oct, 2012 1 commit
    • Simon Peyton Jones's avatar
      Do not instantiate unification variables with polytypes · 10f83429
      Simon Peyton Jones authored
      Without -XImpredicativeTypes, the typing rules say that a function
      should be instantiated only at a *monotype*.  In implementation terms,
      that means that a unification variable should not unify with a type
      involving foralls.  But we were not enforcing that rule, and that
      gave rise to some confusing error messages, such as
        Trac #7264, #6069
      
      This patch adds the test for foralls.  There are consequences
      
       * I put the test in occurCheckExpand, since that is where we see if a
         type can unify with a given unification variable.  So
         occurCheckExpand has to get DynFlags, so it can test for
         -XImpredicativeTypes
      
       * We want this to work
            foo :: (forall a. a -> a) -> Int
            foo = error "foo"
         But that means instantiating error at a polytype!  But error is special
         already because you can instantiate it at an unboxed type like Int#.
         So I extended the specialness to allow type variables of openTypeKind
         to unify with polytypes, regardless of -XImpredicativeTypes.
      
         Conveniently, this works in TcUnify.matchExpectedFunTys, which generates
         unification variable for the function arguments, which can be polymorphic.
      
       * GHC has a special typing rule for ($) (see Note [Typing rule
         for ($)] in TcExpr).  It unifies the argument and result with a
         unification variable to exclude unboxed types -- but that means I
         now need a kind of unificatdion variable that *can* unify with a
         polytype.
      
         So for this sole case I added PolyTv to the data type TcType.MetaInfo.
         I suspect we'll find mor uses for this, and the changes are tiny,
         but it still feel a bit of a hack.  Well the special rule for ($)
         is a hack!
      
      There were some consequential changes in error reporting (TcErrors).
      10f83429
  6. 19 Oct, 2012 1 commit
  7. 01 Oct, 2012 2 commits
  8. 17 Sep, 2012 4 commits
    • Simon Peyton Jones's avatar
    • Simon Peyton Jones's avatar
      Remove cc_ty from CIrredCan and cc_hole_ty from CHoleCan · 1a6ab644
      Simon Peyton Jones authored
      A simple refactoring with no complicated fiddling.
      1a6ab644
    • Simon Peyton Jones's avatar
      Another refactoring of constraints · d30b9cf4
      Simon Peyton Jones authored
      1. Rejig CtLoc
         * CtLoc is now *not* parameterised (much simpler)
         * CtLoc includes the "depth" of the constraint
         * CtLoc includes the TcLclEnv at the birthplace
           That gives (a) the SrcSpan, (b) the [ErrCtxt]
           (c) the [TcIdBinder]
         * The CtLoc of a constraint is no longer in its CtEvidence
         * Where we passed 'depth' before, now we pass CtLoc
      
      2. Some significant refactoring in TcErrors
         * Get rid of cec_extra
         * Traverse every constraint, so that we can be
           sure to generate bindings where necessary.
           (This was really a lurking bug before.)
      
      3. Merge zonking into TcCanonical.  This turned out to be
         almost trivial; just a small change to TcCanonical.flattenTyVar.
      
         The nice consequence is that we don't need to zonk a constraint
         before solving it; instead it gets zonked "on the fly" as it were.
      d30b9cf4
    • Simon Peyton Jones's avatar
      Add type "holes", enabled by -XTypeHoles, Trac #5910 · 8a9a7a8c
      Simon Peyton Jones authored
      This single commit combines a lot of work done by
      Thijs Alkemade <thijsalkemade@gmail.com>, plus a slew
      of subsequent refactoring by Simon PJ.
      
      The basic idea is
      * Add a new expression form "_", a hole, standing for a not-yet-written expression
      * Give a useful error message that
         (a) gives the type of the hole
         (b) gives the types of some enclosing value bindings that
             mention the hole
      
      Driven by this goal I did a LOT of refactoring in TcErrors, which in turn
      allows us to report enclosing value bindings for other errors, not just
      holes.  (Thijs rightly did not attempt this!)
      
      The major data type change is a new form of constraint
        data Ct = ...
          	  | CHoleCan {
          	      cc_ev       :: CtEvidence,
          	      cc_hole_ty  :: TcTauType,
          	      cc_depth    :: SubGoalDepth }
      
      I'm still in two minds about whether this is the best plan. Another
      possibility would be to have a predicate type for holes, somthing like
         class Hole a where
           holeValue :: a
      
      It works the way it is, but there are some annoying special cases for
      CHoleCan (just grep for "CHoleCan").
      8a9a7a8c
  9. 14 Sep, 2012 1 commit
  10. 09 Sep, 2012 1 commit
  11. 06 Sep, 2012 1 commit
  12. 30 Aug, 2012 1 commit
    • Simon Peyton Jones's avatar
      A raft more changes, · 2b69233d
      Simon Peyton Jones authored
       * simplifying and tidying up canonicalisation,
       * removing the flat cache altogether
       * making the FunEq worklist into a deque
      2b69233d
  13. 29 Aug, 2012 1 commit
  14. 28 Aug, 2012 1 commit
  15. 21 Aug, 2012 1 commit
  16. 15 Aug, 2012 1 commit
  17. 10 Jul, 2012 1 commit
  18. 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
  19. 08 Jun, 2012 2 commits
  20. 07 Jun, 2012 1 commit
  21. 22 May, 2012 1 commit
  22. 15 May, 2012 1 commit
    • batterseapower's avatar
      Support code generation for unboxed-tuple function arguments · 09987de4
      batterseapower authored
      This is done by a 'unarisation' pre-pass at the STG level which
      translates away all (live) binders binding something of unboxed
      tuple type.
      
      This has the following knock-on effects:
        * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
        * Various relaxed type checks in typechecker, 'foreign import prim' etc
        * All case binders may be live at the Core level
      09987de4
  23. 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
  24. 25 Apr, 2012 1 commit
    • Simon Peyton Jones's avatar
      More fixes to kind polymorphism, fixes Trac #6035, #6036 · 2316a90d
      Simon Peyton Jones authored
      * Significant refactoring in tcFamPats and tcConDecl
      
      * It seems that we have to allow KindVars (not just
        TcKindVars during kind unification.  See
        Note [Unifying kind variables] in TcUnify.
      
      * Be consistent about zonkQuantifiedTyVars
      
      * Split the TcType->TcType zonker (in TcMType)
         from the TcType->Type   zonker (in TcHsSyn)
        The clever parameterisation was doing my head in,
        and it's only a small function
      
      * Remove some dead code (tcTyVarBndrsGen)
      2316a90d
  25. 13 Apr, 2012 1 commit
    • Simon Peyton Jones's avatar
      Allow kind-variable binders in type signatures · c5554f82
      Simon Peyton Jones authored
      This is the last major addition to the kind-polymorphism story,
      by allowing (Trac #5938)
      
       type family F a   -- F :: forall k. k -> *
       data T a          -- T :: forall k. k -> *
       type instance F (T (a :: Maybe k)) = Char
      
      The new thing is the explicit 'k' in the type signature on 'a',
      which itself is inside a type pattern for F.
      
      Main changes are:
      
      * HsTypes.HsBSig now has a *pair* (kvs, tvs) of binders,
        the kind variables and the type variables
      
      * extractHsTyRdrTyVars returns a pair (kvs, tvs)
        and the function itself has moved from RdrHsSyn to RnTypes
      
      * Quite a bit of fiddling with
           TcHsType.tcHsPatSigType and tcPatSig
        which have become a bit simpler.  I'm still not satisfied
        though.  There's some consequential fiddling in TcRules too.
      
      * Removed the unused HsUtils.collectSigTysFromPats
      
      There's a consequential wibble to Haddock too
      c5554f82
  26. 04 Apr, 2012 1 commit
  27. 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
  28. 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
  29. 17 Feb, 2012 1 commit
  30. 16 Feb, 2012 1 commit
  31. 19 Jan, 2012 1 commit
  32. 13 Jan, 2012 1 commit