[GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary

[GHC]

#13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read
more cautionary
-------------------------------------+-------------------------------------
        Reporter:  sjakobi           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Core Libraries    |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by sjakobi:

@@ -32,1 +32,1 @@
- Ragarding point 2 (`readEither`), I have some qualms whether `readEither`
+ Regarding point 2 (`readEither`), I have some qualms whether `readEither`

New description:

 = Motivation =

 `read` is an easy way to introduce runtime exceptions into programs, but
 its documentation doesn't sufficiently warn of this danger. `read`'s safe
 alternatives, `Text.Read.readMaybe` and `Text.Read.readEither`, are
 relatively unknown and too hard to find.

 = Proposal =

 == Summary ==

 1. Add `readMaybe` to the `Prelude`
 2. Add `readEither` to the `Prelude`
 3. Change the documentation for `read` to point out the partiality and to
 recommend the above alternatives.

 == 3. Improve the documentation for `read` ==

 The haddocks for `read` currently read:

 > The `read` function reads input from a string, which must be completely
 consumed by the input process.

 I propose to add the following paragraph:

 > Note: `read` will throw an error if the parse fails.
 > If there's any uncertainty w.r.t. the shape of the input, `readMaybe` or
 `readEither` should be used instead.

 == Qualifications ==

 Regarding point 2 (`readEither`), I have some qualms whether `readEither`
 ([http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-
 Read.html#v:readEither docs])  offers sufficient additional benefit over
 `readMaybe` to also warrant inclusion in `Prelude`. While `readEither`
 does give additional info on the kind of parse failures, that information
 is encoded in a `String` error message, from which it must be parsed if it
 is needed in the program.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13013#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler