On Dec 27, 2016 10:59 PM, "Simon Jakobi via Libraries" < libraries@haskell.org> wrote: read [1] 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 [2] and Text.Read.readEither [3], are relatively unknown and too hard to find. A while back I brought up the idea of adding custom warning "classes", allowing such functions to be tagged partial. I should probably put together a proper proposal now that we have that process. Personally, I'd love to remove read from the Prelude, but that would be hard. 1. Add readMaybe to the Prelude +1 2. Add readEither to the Prelude +1 3. Change the documentation for read to point out the partiality and to recommend the above alternatives: +1 > If there's any uncertainty w.r.t. the shape of the input, readMaybe or readEither should be used instead. I would put it more strongly: read should be applied only to strings that are known to have been produced by methods of the Show class. Design issues: I am somewhat doubtful about the benefit of readEither over readMaybe: 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. It's still the right way to handle error reporting for Read. Very wrong: do x <- read <$> getInput use x Correct, in some contexts, but extremely lousy: do x <- read <$> getInput evaluate (force x) use x Correct, but uninformative: do Just x <- readMaybe <$> getInput use x Correct and informative: do ip <- readEither <$> getInput either (throwIO . parseError) use ip (For some value of parseError) Or, when reasonable, do ip <- readEither <$> getInput either (\m -> displayMessage m *> tryAgain) ip