1. 17 Jan, 2016 1 commit
  2. 23 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored
      This introduces "freezing," an operation which prevents further
      locations from being appended to a CallStack.  Library authors may want
      to prevent CallStacks from exposing implementation details, as a matter
      of hygiene. For example, in
      
      ```
      head [] = error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      including the call-site of `error` in `head` is not strictly necessary
      as the error message already specifies clearly where the error came
      from.
      
      So we add a function `freezeCallStack` that wraps an existing CallStack,
      preventing further call-sites from being pushed onto it. In other words,
      
      ```
      pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
      ```
      
      Now we can define `head` to not produce a CallStack at all
      
      ```
      head [] =
        let ?callStack = freezeCallStack emptyCallStack
        in error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      ---
      
      1. We add the `freezeCallStack` and `emptyCallStack` and update the
         definition of `CallStack` to support this functionality.
      
      2. We add `errorWithoutStackTrace`, a variant of `error` that does not
         produce a stack trace, using this feature. I think this is a sensible
         wrapper function to provide in case users want it.
      
      3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
         rationale is that base does not export any functions that use CallStacks
         (except for `error` and `undefined`) so there's no way for the stack
         traces (from Implicit CallStacks) to include user-defined functions.
         They'll only contain the call to `error` itself. As base already has a
         good habit of providing useful error messages that name the triggering
         function, the stack trace really just adds noise to the error. (I don't
         have a strong opinion on whether we should include this third commit,
         but the change was very mechanical so I thought I'd include it anyway in
         case there's interest)
      
      4. Updates tests in `array` and `stm` submodules
      
      Test Plan: ./validate, new test is T11049
      
      Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1628
      
      GHC Trac Issues: #11049
      380b25ea
  3. 19 Nov, 2015 1 commit
  4. 23 Feb, 2015 1 commit
    • redneb's avatar
      Provide a faster implementation for the Read Integer instance · a5a4c256
      redneb authored
      Summary:
      The current implementation of the Read Integer instance has quadratic
      complexity and thus performs badly on large inputs. This patch provides a
      rather simple sub-quadratic algorithm. For small inputs, we use the old
      algorithm (there is a small penalty for that). The gains for large
      inputs can be dramatic: on my system, the time to perform
          read (take 1000000 $ cycle "1234567890") :: Integer
      drops from 65 seconds to less than a second.
      
      Note that we already provide an ad-hoc instance for Show Integer, so this
      patch essentially does the same thing for Read Integer.
      
      Test Plan: Check that read :: String -> Integer returns correct results for inputs of various sizes.
      
      Reviewers: austin, hvr
      
      Reviewed By: austin, hvr
      
      Subscribers: ekmett, thomie
      
      Differential Revision: https://phabricator.haskell.org/D645
      
      GHC Trac Issues: #10067
      a5a4c256
  5. 16 Dec, 2014 1 commit
  6. 11 Oct, 2014 1 commit
  7. 24 Sep, 2014 1 commit
  8. 18 Sep, 2014 1 commit
  9. 01 Nov, 2013 1 commit
  10. 22 Sep, 2013 1 commit
  11. 21 Sep, 2013 2 commits
    • Herbert Valerio Riedel's avatar
      Add Haddock `/Since: 4.6.0.0/` comments to symbols · 2642d9f6
      Herbert Valerio Riedel authored
      
      
      This commit retroactively adds `/Since: 4.6.0.0/` annotations to symbols
      newly added/exposed in `base-4.6.0.0` (as shipped with GHC 7.6.1).
      
      See also 6368362f which adds the respective annotation for symbols newly
      added in `base-4.7.0.0` (that goes together with GHC 7.8.1).
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      2642d9f6
    • Herbert Valerio Riedel's avatar
      Add Haddock `/Since: 4.7.0.0/` comments to new symbols · 77f32dad
      Herbert Valerio Riedel authored
      
      
      These annotations were added in such a way, that the line
      
      {{{
      /Since: 4.7.0.0/
      }}}
      
      represents the last paragraph of the Haddock comment.
      
      Maybe Haddock will have support for this meta-syntax at some point, and
      be able to inherited the since-version property to the children of an
      annotated symbol and display the since-version property in the rendered
      documentation only in cases when it's not visually obvious (for
      instance, when re-exporting documentation strings).
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      77f32dad
  12. 17 Sep, 2013 2 commits
  13. 08 Jan, 2013 1 commit
  14. 03 Jan, 2013 1 commit
  15. 21 Dec, 2012 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. 02 Jul, 2012 1 commit
  18. 11 Mar, 2012 1 commit
  19. 01 Mar, 2012 3 commits
  20. 28 Feb, 2012 2 commits
  21. 26 Oct, 2011 1 commit
  22. 12 Oct, 2011 1 commit
  23. 19 Sep, 2011 2 commits
  24. 18 Jun, 2011 1 commit
  25. 28 Jan, 2011 1 commit
  26. 09 Jul, 2009 1 commit
  27. 05 Aug, 2008 1 commit
  28. 16 Jun, 2008 1 commit
  29. 05 Mar, 2008 1 commit
  30. 07 Feb, 2005 1 commit
  31. 11 Jan, 2005 1 commit
  32. 06 Oct, 2003 1 commit
  33. 22 Aug, 2003 1 commit
  34. 19 Aug, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-08-19 16:39:13 by simonmar] · fbf9b826
      simonmar authored
      Use the wide-char classifications from the C library if available.
      This gives us Unicode-aware isLower, isUpper, isAlpha etc.
      
      On Unix, you have to set your locale to something.  This is usually
      done by setting the environment variable LANG, eg.
      
        export LANG=en
      
      This stuff *should* also work on Windows, except that Windows uses a
      16-bit wchar_t so will get it wrong for characters > '\xffff'.  However,
      I figured it was better to use the system-supplied functionality
      rather than trying to implement this stuff ourselves.
      fbf9b826