Skip to content

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 by Simon Jakobi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information