1. 18 Mar, 2012 1 commit
  2. 14 Mar, 2012 1 commit
    • 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
  3. 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
  4. 22 Feb, 2012 1 commit
  5. 17 Feb, 2012 2 commits
  6. 16 Feb, 2012 2 commits
  7. 06 Feb, 2012 1 commit
    • Simon Peyton Jones's avatar
      Refactor HsDecls again, to put family instances in InstDecl · f92591de
      Simon Peyton Jones authored
      This continues the clean up of the front end.  Since they
      were first invented, type and data family *instance* decls
      have been in the TyClDecl data type, even though they always
      treated separately.
      
      This patch takes a step in the right direction
        * The InstDecl type now includes both class instances and
          type/data family instances
      
        * The hs_tyclds field of HsGroup now never has any family
          instance declarations in it
      
      However a family instance is still a TyClDecl.  It should really
      be a separate type, but that's the next step.
      
      All this was provoked by fixing Trac #5792 in the HEAD.
      (I did a less invasive fix on the branch.)
      f92591de
  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"
      5851f847
  9. 17 Jan, 2012 1 commit
  10. 09 Jan, 2012 1 commit
    • Iavor S. Diatchki's avatar
      Change -XTypeOperators to treat all type-operators as type-constructors. · 85926ae6
      Iavor S. Diatchki authored
      Previously, only type operators starting with ":" were type constructors,
      and writing "+" in a type resulted in a type variable.  Now, type
      variables are always ordinary identifiers, and all operators are treated
      as constructors.  One can still write type variables in infix form though,
      for example, "a `fun` b" is a type expression with 3 type variables: "a",
      "fun", and "b".
      
      Writing (+) in an import/export list always refers to the value (+)
      and not the type.   To refer to the type one can write either "type (+)",
      or provide an explicit suobrdinate list (e.g., "(+)()").  For clarity,
      one can also combine the two, for example "type (+)(A,B,C)" is also
      accepted and means the same thing as "(+)(A,B,C)" (i.e., export the type
      (+), with the constructors A,B,and C).
      85926ae6
  11. 23 Dec, 2011 2 commits
  12. 19 Dec, 2011 1 commit
  13. 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.
      2e6dcdf7
  14. 28 Nov, 2011 2 commits
  15. 25 Nov, 2011 1 commit
  16. 24 Nov, 2011 1 commit
    • Simon Peyton Jones's avatar
      Support "phase control" for SPECIALISE pragmas · 814d8641
      Simon Peyton Jones authored
      This featurelet allows Trac #5237 to be fixed.
      The idea is to allow SPECIALISE pragmas to specify
      the phases in which the RULE is active, just as you can
      do with RULES themselves.
        {-# SPECIALISE [1] foo :: Int -> Int #-}
      
      This feature is so obvious that not having it is really a bug.
      There are, needless to say, a few wrinkles.  See
         Note [Activation pragmas for SPECIALISE]
      in DsBinds
      814d8641
  17. 17 Nov, 2011 1 commit
  18. 16 Nov, 2011 1 commit
    • dreixel's avatar
      Changes to the kind checker · e589a49d
      dreixel authored
      We now always check against an expected kind. When we really don't know what
      kind to expect, we match against a new meta kind variable.
      
      Also, we are more explicit about tuple sorts:
        HsUnboxedTuple                  -> Produced by the parser
        HsBoxedTuple                    -> Certainly a boxed tuple
        HsConstraintTuple               -> Certainly a constraint tuple
        HsBoxedOrConstraintTuple        -> Could be a boxed or a constraint
                                        tuple. Produced by the parser only,
                                        disappears after type checking
      e589a49d
  19. 11 Nov, 2011 2 commits
    • dreixel's avatar
      Restore file mode · 3b0e507c
      dreixel authored
      3b0e507c
    • 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
      09015be8
  20. 09 Nov, 2011 1 commit
  21. 02 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Overhaul of infrastructure for profiling, coverage (HPC) and breakpoints · 7bb0447d
      Simon Marlow authored
      User visible changes
      ====================
      
      Profilng
      --------
      
      Flags renamed (the old ones are still accepted for now):
      
        OLD            NEW
        ---------      ------------
        -auto-all      -fprof-auto
        -auto          -fprof-exported
        -caf-all       -fprof-cafs
      
      New flags:
      
        -fprof-auto              Annotates all bindings (not just top-level
                                 ones) with SCCs
      
        -fprof-top               Annotates just top-level bindings with SCCs
      
        -fprof-exported          Annotates just exported bindings with SCCs
      
        -fprof-no-count-entries  Do not maintain entry counts when profiling
                                 (can make profiled code go faster; useful with
                                 heap profiling where entry counts are not used)
      
      Cost-centre stacks have a new semantics, which should in most cases
      result in more useful and intuitive profiles.  If you find this not to
      be the case, please let me know.  This is the area where I have been
      experimenting most, and the current solution is probably not the
      final version, however it does address all the outstanding bugs and
      seems to be better than GHC 7.2.
      
      Stack traces
      ------------
      
      +RTS -xc now gives more information.  If the exception originates from
      a CAF (as is common, because GHC tends to lift exceptions out to the
      top-level), then the RTS walks up the stack and reports the stack in
      the enclosing update frame(s).
      
      Result: +RTS -xc is much more useful now - but you still have to
      compile for profiling to get it.  I've played around a little with
      adding 'head []' to GHC itself, and +RTS -xc does pinpoint the problem
      quite accurately.
      
      I plan to add more facilities for stack tracing (e.g. in GHCi) in the
      future.
      
      Coverage (HPC)
      --------------
      
       * derived instances are now coloured yellow if they weren't used
       * likewise record field names
       * entry counts are more accurate (hpc --fun-entry-count)
       * tab width is now correct (markup was previously off in source with
         tabs)
      
      Internal changes
      ================
      
      In Core, the Note constructor has been replaced by
      
              Tick (Tickish b) (Expr b)
      
      which is used to represent all the kinds of source annotation we
      support: profiling SCCs, HPC ticks, and GHCi breakpoints.
      
      Depending on the properties of the Tickish, different transformations
      apply to Tick.  See CoreUtils.mkTick for details.
      
      Tickets
      =======
      
      This commit closes the following tickets, test cases to follow:
      
        - Close #2552: not a bug, but the behaviour is now more intuitive
          (test is T2552)
      
        - Close #680 (test is T680)
      
        - Close #1531 (test is result001)
      
        - Close #949 (test is T949)
      
        - Close #2466: test case has bitrotted (doesn't compile against current
          version of vector-space package)
      7bb0447d
  22. 31 Oct, 2011 2 commits
  23. 10 Oct, 2011 1 commit
  24. 29 Sep, 2011 1 commit
  25. 27 Sep, 2011 1 commit
  26. 09 Sep, 2011 1 commit
  27. 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
  28. 01 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Get rid of associated-type default declarations · 5e102e64
      Simon Peyton Jones authored
      We had the idea that you might be able to define
      a default instance for an associated type family, thus:
      
         class C a where
           type T a :: *
           type T a = a -> a
      
      It's an idea that makes sense, but it was only 10% implemented.
      This patch just removes that misleading 10%.
      5e102e64
  29. 18 Aug, 2011 1 commit
  30. 02 Aug, 2011 1 commit
    • Simon Peyton Jones's avatar
      Refactor the imports of InteractiveContext · 35d213ab
      Simon Peyton Jones authored
      Instead of two fields
         ic_toplev_scope :: [Module]
         ic_imports      :: [ImportDecl RdrName]
      
      we now just have one
         ic_imports :: [InteractiveImport]
      with the auxiliary data type
         data InteractiveImport
          = IIDecl (ImportDecl RdrName)  -- Bring the exports of a particular module
          	   	       		   -- (filtered by an import decl) into scope
      
          | IIModule Module	-- Bring into scope the entire top-level envt of
          	     		-- of this module, including the things imported
      			-- into it.
      
      This makes lots of code less confusing.  No change in behaviour.
      It's preparatory to fixing Trac #5147.
      
      While I was at I also
        * Cleaned up the handling of the "implicit" Prelude import
          by adding a ideclImplicit field to ImportDecl.  This
          significantly reduces plumbing in the handling of
          the implicit Prelude import
      
        * Used record notation consistently for ImportDecl
      35d213ab
  31. 27 Jul, 2011 1 commit
  32. 13 Jul, 2011 1 commit
  33. 12 Jul, 2011 1 commit
  34. 18 Jun, 2011 1 commit