1. 19 Dec, 2012 1 commit
  2. 26 Nov, 2012 1 commit
  3. 21 Nov, 2012 1 commit
  4. 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
  5. 19 Oct, 2012 3 commits
  6. 15 Oct, 2012 1 commit
  7. 12 Oct, 2012 1 commit
    • Simon Peyton Jones's avatar
      Ensure we produce a FunTy for functions (Trac #7312) · 9991890d
      Simon Peyton Jones authored
      The issue here was with a function type written prefix
        (->) a b
      where we were not generating a FunTy, which blew the
      invariant that function types are always FunTys.  We
      can't look at the TyCon directly because it may be
      knot-tied, so we look at the name instead.
      9991890d
  8. 28 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of kind errors · 9a058b17
      Simon Peyton Jones authored
      * Treat kind-equality constraints as *derived* equalities,
        with no evidence.  That is really what they are at the moment.
      
      * Get rid of EvKindCast and friends.
      
      * Postpone kind errors properly to the constraint solver
        (lots of small knock-on effects)
      
      I moved SwapFlag to BasicTypes as well
      9a058b17
  9. 21 Sep, 2012 1 commit
  10. 17 Sep, 2012 1 commit
  11. 10 Sep, 2012 1 commit
  12. 06 Sep, 2012 1 commit
  13. 15 Aug, 2012 1 commit
  14. 14 Aug, 2012 1 commit
  15. 14 Jul, 2012 1 commit
  16. 10 Jul, 2012 1 commit
    • Simon Peyton Jones's avatar
      More changes to kind inference for type and class declarations · 3fe3ef50
      Simon Peyton Jones authored
      These should fix #7024 and #7022, among others.
      
      The main difficulty was that we were getting occ-name clashes
      between kind and type variables in TyCons, when spat into an
      interface file. The new scheme is to tidy TyCons during the
      conversoin into IfaceSyn, rather than trying to generate them
      pre-tidied, which was the already-unsatisfactory previous plan.
      
      There is the usual wave of refactorig as well.
      3fe3ef50
  17. 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
  18. 12 Jun, 2012 1 commit
  19. 07 Jun, 2012 2 commits
    • Simon Peyton Jones's avatar
      177134e9
    • Simon Peyton Jones's avatar
      Support polymorphic kind recursion · c9117200
      Simon Peyton Jones authored
      This is (I hope) the last major patch for kind polymorphism.
      The big new feature is polymorphic kind recursion when you
      supply a complete kind signature for a type constructor.
      (I've documented it in the user manual too.)
      
      This fixes Trac #6137, #6093, #6049.
      
      The patch also makes type/data families less polymorphic by default.
         data family T a
      now defaults to T :: * -> *
      If you want T :: forall k. k -> *, use
         data family T (a :: k)
      
      This defaulting to * is done whenever there is a
      "complete, user-specified kind signature", something that is
      carefully defined in the user manual.
      
      Hurrah!
      c9117200
  20. 05 Jun, 2012 1 commit
  21. 24 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. 11 May, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor LHsTyVarBndrs to fix Trac #6081 · fc8959ac
      Simon Peyton Jones authored
      This is really a small change, but it touches a lot of files quite
      significantly. The real goal is to put the implicitly-bound kind
      variables of a data/class decl in the right place, namely on the
      LHsTyVarBndrs type, which now looks like
      
        data LHsTyVarBndrs name
          = HsQTvs { hsq_kvs :: [Name]
                   , hsq_tvs :: [LHsTyVarBndr name]
            }
      
      This little change made the type checker neater in a number of
      ways, but it was fiddly to push through the changes.
      fc8959ac
  24. 27 Apr, 2012 1 commit
  25. 25 Apr, 2012 3 commits
  26. 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
  27. 05 Apr, 2012 1 commit
  28. 14 Mar, 2012 2 commits
    • Simon Peyton Jones's avatar
      Deal with kind variables brought into scope by a kind signature · 431c05b3
      Simon Peyton Jones authored
      This fixes Trac #5937, where a kind variable is mentioned only
      in the kind signature of a GADT
         data SMaybe :: (k -> *) -> Maybe k -> * where ...
      
      The main change is that the tcdKindSig field of TyData and TyFamily
      now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
      part deals with the kind variables that the signature may bind.
      
      I also removed the now-unused PostTcKind field of UserTyVar and
      KindedTyVar.
      431c05b3
    • Simon Peyton Jones's avatar
      Deal with kind variables brought into scope by a kind signature · 54eb0301
      Simon Peyton Jones authored
      This fixes Trac #5937, where a kind variable is mentioned only
      in the kind signature of a GADT
         data SMaybe :: (k -> *) -> Maybe k -> * where ...
      
      The main change is that the tcdKindSig field of TyData and TyFamily
      now has type Maybe (HsBndrSig (LHsKind name)), where the HsBndrSig
      part deals with the kind variables that the signature may bind.
      
      I also removed the now-unused PostTcKind field of UserTyVar and
      KindedTyVar.
      54eb0301
  29. 09 Mar, 2012 1 commit
  30. 04 Mar, 2012 1 commit
    • Simon Peyton Jones's avatar
      Tidy up the handling of kind generalisation · e0c849e0
      Simon Peyton Jones authored
      In particular in forall abc. <blah> we should
      kind generalise over <blah> as well as over the
      kinds of a,b,c.
      
      This fixes bug (in Trac #5862, caught by Lint) in the handling of
        data SMaybe a where
           SNothing :: SMaybe 'Nothing
      where I didn't get a sufficiently general kind. And it's simpler.
      e0c849e0
  31. 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
  32. 17 Feb, 2012 1 commit
  33. 16 Feb, 2012 1 commit
  34. 06 Feb, 2012 1 commit