Re: Proposal: Add readMaybe (and possibly readEither) to Prelude, make Haddocks for read more cautionary

On Thu, 2016-12-29 at 03:42 +0100, Simon Jakobi via Libraries wrote:

2016-12-28 20:41 GMT+01:00 Henning Thielemann :

...

What precisely is the problem of importing readMaybe and readEither from Text.Read?

Those who are aware that these functions reside in Text.Read can of course import them with little effort.

The point of exporting these functions from the Prelude is to present them to everyone else, particularly newcomers who might otherwise use read without being aware of its partiality.

Documenting partiality of `read` should be enough IMO.

...

The current state means you have to import them, that is, you have to add one import line and this solution works back to GHC- 7.6. If we add readMaybe and readEither to Prelude, you may be happy to not add a new import line but you force your library users to the newest version of GHC and you risk to make his programs uncompilable because it may depend on other packages that are not (yet) updated to the newest GHC. If you care for multiple versions of GHC you have to make much more cumbersome import statements or add multiple lines of preprocessor.

These concerns apply to any change to the Prelude.

Yet it is a valid argument. We should be careful with Prelude.

...

This seems to be too much effort if 'read' calls should be replaced by other functions anyway.

I disagree. While Read may not be the right way (TM) to parse numbers, it currently is the standard way presented to newcomers. I invite you to google for "haskell parse int string"!

I don't want to discourage anyone from bringing a better solution into base, but at this point I would like to incrementally improve the status quo. I think the cost that we impose on package maintainers by introducing readMaybe (and possibly readEither) into Prelude is reasonable.

Incremental improvements should go in some specific direction, otherwise they are random steps in the design space. I'm not sure optimizing for newcomers is a good direction. If the goal is to remove partial functions from Prelude, then there should be a clear plan where adding `readMaybe` is just the first step. Without the plan we'll never do the next step or we'll do it in the opposite direction. Adding `readMaybe` to Prelude makes it discoverable, but we can't add every useful function into Prelude. IMO fat Prelude in the reason for bad discoverability -- if something is not in Prelude, then it doesn't exist, because Prelude already contains (worse) alternative. To solve that, we can move everything related to `Read` type class into one module, e.g. Data.Read, and then `read` and `readMaybe` will have the same discoverability. If it is the goal, then adding `readMaybe` to Prelude is a step in wrong direction. I'm against the proposal (except the documentation part) until it is presented in wider context.

Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries