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

[Edward Kmett]

On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 2016-12-29 21:12, Andreas Abel wrote:
> >
> > I am in favor of deprecating "read" and pointing to a total version in a
> > library.  Otherwise, I'd leave the Prelude unchanged.
> >
>
> But that throws a wrench in the works of people who want to be "-Wall"
> clean... unless you mean "deprecated" in the sense of being *documented*
> as deprecated rather than actually marked as such (causing deprecation
> warnings during compilation).
>

Indeed.

I'm not sure actually... do we have fine-grained deprecation warnings
> yet?[1]


We do not. There has been some work on breaking up the monolithic set of
warnings and being a bit more regular about how we handle them, but not
individual groups of deprecations.


> I.e. can we turn on/off individual deprecation warnings with
> compiler switches? If so, then just deprecating read and pointing to a
> readMaybe in some module might be the optimal solution here.
>

I'm strongly -1 on adding a full-fledged DEPRECATED flag to read. The
amount of noise that would generate would dwarf anything else under
discussion by multiple orders of magnitude. It is in the Haskell Report and
it has been used a lot for a couple of decades now.

On the other hand, whether or not anything changes in Prelude, I'm a strong
+1 on adding documentation to it that mentions these safer alternatives,
and where to get them if necessary.

[1] If we don't then I honestly think that this may be the single most
> important feature to be able to move forward wrt. the Prelude. (Well, a
> "go fix" type tool might be even better, but that's not likely to happen
> any time soon.)


The amount of CPP running around in Haskell with any sort of long support
window makes 'go fix' tools quite shockingly difficult for us to get right.

I'm a weak +1 on adding re-export of the existing readMaybe and readEither
to the Prelude, possibly after a warning period. They are sufficiently
obscure names that I'm personally not expecting many name conflicts at all
and the changes in base are minimal as the classes and 'read' are already
re-exports from the same place, so there isn't much of an engineering
challenge.

I do think if we're going to include readMaybe there isn't much point in
not including the slightly more powerful readEither.

-Edward



> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161229/d0d5ab6f/attachment.html>