Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,334
    • Issues 4,334
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 368
    • Merge Requests 368
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #13013

Closed
Open
Opened Dec 20, 2016 by Simon Jakobi@sjakobiDeveloper

Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary

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 (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.

Edited Mar 10, 2019 by Simon Jakobi
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#13013