1. 15 Jun, 2012 1 commit
  2. 12 Jun, 2012 2 commits
    • Ross Paterson's avatar
      tweak documentation of mdo/rec · 96a37685
      Ross Paterson authored
      96a37685
    • Simon Peyton Jones's avatar
      Revive 'mdo' expressions, per discussion in Trac #4148 · 4f8e86b4
      Simon Peyton Jones authored
      Summary:
        - mdo expressions are enabled by RecursiveDo pragma
      
        - mdo expressions perform full segmentation
      
        - 'rec' groups inside 'do' are changed so they do *not*
          perform any segmentation.
      
        - Both 'mdo' and 'rec' are enabled by 'RecursiveDo'
          'DoRec' is deprecated in favour of 'RecursiveDo'
          (The 'rec' keyword is also enabled by 'Arrows', as now.)
      
      Thanks to Levent for doing all the work
      4f8e86b4
  3. 07 Jun, 2012 2 commits
    • 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
    • Simon Peyton Jones's avatar
  4. 31 Mar, 2012 1 commit
  5. 30 Mar, 2012 1 commit
  6. 16 Mar, 2012 1 commit
  7. 09 Mar, 2012 1 commit
  8. 16 Jan, 2012 1 commit
  9. 28 Dec, 2011 1 commit
  10. 23 Dec, 2011 1 commit
  11. 13 Dec, 2011 1 commit
  12. 12 Dec, 2011 1 commit
  13. 26 Nov, 2011 1 commit
  14. 25 Nov, 2011 1 commit
  15. 24 Nov, 2011 4 commits
  16. 22 Nov, 2011 1 commit
  17. 17 Nov, 2011 1 commit
  18. 16 Nov, 2011 3 commits
  19. 15 Nov, 2011 1 commit
  20. 09 Nov, 2011 1 commit
  21. 07 Nov, 2011 1 commit
  22. 04 Nov, 2011 1 commit
  23. 24 Oct, 2011 1 commit
  24. 22 Oct, 2011 3 commits
  25. 04 Oct, 2011 1 commit
  26. 27 Sep, 2011 2 commits
  27. 09 Sep, 2011 1 commit
  28. 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
  29. 05 Sep, 2011 1 commit
  30. 02 Sep, 2011 1 commit
    • Simon Peyton Jones's avatar
      Backtrack on the wierd special case of data family exports · f5c0851a
      Simon Peyton Jones authored
      I had second thoughts on the "data family export" question.
      Rather than add a wierd special case it seems better to be
      simple and consistent.  So this patch
      
       * Reverts to the simple behaviour:
           module M where { ... }
         exports only what is defined in M, ie NOT any
         imported data families.
         See Note [Exports of data families] in RnNames
      
      * Documents this behaviour in the user manual, and clarifies
        what was there before.
      f5c0851a