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

[Yuras Shumovich]

On Thu, 2016-12-29 at 03:42 +0100, Simon Jakobi via Libraries wrote:
> 2016-12-28 20:41 GMT+01:00 Henning Thielemann <lemming at henning-thiele
> mann.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.

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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries