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