1. 27 Oct, 2012 2 commits
    • 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
    • illissius's avatar
  2. 25 Oct, 2012 4 commits
  3. 23 Oct, 2012 1 commit
  4. 21 Oct, 2012 1 commit
  5. 19 Oct, 2012 1 commit
  6. 16 Oct, 2012 3 commits
  7. 15 Oct, 2012 3 commits
  8. 04 Oct, 2012 2 commits
  9. 03 Oct, 2012 1 commit
  10. 29 Sep, 2012 2 commits
  11. 23 Sep, 2012 2 commits
  12. 21 Sep, 2012 1 commit
  13. 20 Sep, 2012 4 commits
  14. 17 Sep, 2012 1 commit
  15. 13 Sep, 2012 1 commit
  16. 09 Sep, 2012 1 commit
  17. 28 Aug, 2012 1 commit
  18. 24 Aug, 2012 1 commit
  19. 21 Aug, 2012 2 commits
  20. 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
  21. 15 Aug, 2012 2 commits
  22. 13 Aug, 2012 2 commits
  23. 10 Aug, 2012 1 commit