1. 17 Nov, 2015 1 commit
    • quchen's avatar
      MonadFail proposal, phase 1 · 233d1312
      quchen authored
      This implements phase 1 of the MonadFail proposal (MFP, #10751).
      
      - MonadFail warnings are all issued as desired, tunable with two new flags
      - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings`
        (but it's disabled by default right now)
      
      Credits/thanks to
      - Franz Thoma, whose help was crucial to implementing this
      - My employer TNG Technology Consulting GmbH for partially funding us
        for this work
      
      Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma
      
      Reviewed By: hvr, bgamari, fmthoma
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1248
      
      GHC Trac Issues: #10751
      233d1312
  2. 16 Nov, 2015 1 commit
  3. 07 Jul, 2015 1 commit
  4. 16 Dec, 2014 1 commit
  5. 18 Oct, 2014 1 commit
  6. 01 Oct, 2014 1 commit
  7. 28 Sep, 2014 2 commits
  8. 26 Sep, 2014 1 commit
  9. 24 Sep, 2014 1 commit
  10. 21 Sep, 2014 2 commits
  11. 18 Sep, 2014 6 commits
  12. 09 Sep, 2014 2 commits
    • Herbert Valerio Riedel's avatar
      base: replace ver 4.7.1.0 references by 4.8.0.0 · 68ecc578
      Herbert Valerio Riedel authored
      Since we now had to major bump due to AMP being landed, `base-4.7.1.0` is not
      gonna happen, as we're going straight for a `base-4.8.0.0` release.
      
      [skip ci] since this is a doc-only change
      68ecc578
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  13. 28 Aug, 2014 1 commit
  14. 14 May, 2014 1 commit
  15. 17 Sep, 2013 1 commit
  16. 27 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Remove commented types in module export lists · fda30027
      ian@well-typed.com authored
      These comments are rather less useful now that haddock can give docs
      with the same informatino in the module synopsis.
      
      Having to maintain them when making changes to the library is a pain,
      and when people forget about doing so there is nothing that checks that
      the comments are right, so mistakes tend to linger.
      
      Of the comments that my script detected, 78 of 684 were already
      incorrect in one way or another, e.g. missing context:
          Text.Show.showsPrec
          Comment type: Int -> a -> ShowS
          Actual type:  Show a => Int -> a -> ShowS
      wrong context:
          Numeric.readInt
          Comment type: Integral a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
          Actual type:  Num a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
      not following a class change (e.g. Num losing its Eq superclass):
          Text.Read.Lex.readOctP
          Comment type: Num a => ReadP a
          Actual type:  (Eq a, Num a) => ReadP a
      not following the Exceptions change:
          GHC.Conc.childHandler
          Comment type: Exception -> IO ()
          Actual type:  SomeException -> IO ()
      or just always been wrong:
          GHC.Stable.deRefStablePtr
          Comment type: StablePtr a -> a
          Actual type:  StablePtr a -> IO a
      fda30027
  17. 20 Aug, 2012 1 commit
    • pcapriotti's avatar
      Improve definition of forever (#5205) · b3ef6457
      pcapriotti authored
      The previous implementation was:
      
          forever a = a >> forever a
      
      which can create a space leak in some cases, even with optimizations.
      The current implementation:
      
          forever a = let a' = a >> a' in a'
      
      prevents repeated thunk allocations by creating a single thunk for the
      final result, even without optimizations.
      b3ef6457
  18. 18 Jun, 2011 1 commit
  19. 09 Jun, 2011 1 commit
  20. 28 Jan, 2011 1 commit
  21. 17 Sep, 2009 1 commit
  22. 01 Jul, 2010 2 commits
  23. 24 Jun, 2010 1 commit
  24. 16 Jan, 2010 1 commit
  25. 08 Jan, 2010 1 commit
  26. 16 Jun, 2008 1 commit
  27. 05 Mar, 2008 1 commit
  28. 29 Jan, 2008 1 commit
  29. 26 Nov, 2007 1 commit
  30. 13 Nov, 2006 1 commit
  31. 30 Aug, 2006 1 commit