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

[Simon Jakobi]

2016-12-28 20:41 GMT+01:00 Henning Thielemann <lemming at henning-thielemann.de>:
> 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.

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

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

Cheers,
Simon