[GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary
#13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = 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 == Ragarding 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 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by sjakobi): For context, the idea for this proposal came up in [https://www.reddit.com/r/haskell/comments/5j8mpx/haskell_pitfalls/dben8h2/ this discussion on r/haskell]. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This would be a good addition -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm personally weakly against this proposal as names are very much not taken by `Prelude` lightly. To put things in perspective, we've had precisely one wave of additions to the names taken by the Prelude in 18 years, and then it was part of a very contentious and public process. That said, this belongs as a `libraries@` mailing list proposal at this stage, rather than as a ticket here. If clear consensus arises from the `libraries@` proposal, ''then'' this would become the correct venue to put the feet of the core libraries committee to the fire to get it implemented. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:4 ekmett]:
I'm personally weakly against this proposal as names are very much not taken by `Prelude` lightly.
That said, this belongs as a `libraries@` mailing list proposal at this stage, rather than as a ticket here. If clear consensus arises from the `libraries@` proposal, ''then'' this would become the correct venue to put
To be clear, the issue is that the newly exposed `readMaybe` and `readEither` names could clash with pre-existing definitions that use the same names, right? the feet of the core libraries committee to the fire to get it implemented. Actually I wanted to send this proposal directly to the libraries mailing list, but then decided otherwise after reading [https://wiki.haskell.org/Library_submissions#Guide_to_proposers this "guide for proposers"]. If that guide is out of date, it would be great if someone could update it to reflect the current practice. I'll write the email in a few days once I'm back from Christmas holidays. Would a discussion period of 4 weeks be appropriate? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by ekmett):
To be clear, the issue is that the newly exposed `readMaybe` and `readEither` names could clash with pre-existing definitions that use the same names, right?
Yep. Four weeks with the holidays probably makes sense. The phrasing in that section was largely put together to encourage folks patching the larger diaspora of packages that fall under the core libraries committee preview to actually use the issue trackers in question -- mostly because `libraries@` won't care about, say, minutiae about how some combinators in the `unix` package behave on OpenBSD. I probably should add some language encouraging `base`- and especially `Prelude`-affecting proposals to expect to always have to go through `libraries@` as the impact spreads to everyone. Anything submitted here is likely to get maybe 5-10 pairs of eyeballs on it. Submitting to `libraries@` enables a lot more feedback. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Comment (by sjakobi): Here is the my email to the libraries mailing list: https://mail.haskell.org/pipermail/libraries/2016-December/027496.html -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13013#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC