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

[Andreas Abel]

When updating the documentation for Read, one can at the same time 
stress that this class is for parsing values in *Haskell* syntax.  Same 
for Show, it should be stressed that it is for printing values into 
their *Haskell* linearization.

I'd guess "Show" is the most abused type class.  (Our own code base, 
Agda, is a prime example for this.)

Currently we have:

https://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Show.html

   Converting values to readable strings: the Show class and associated 
functions.

https://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html

   Converting strings to values.

This description is way too generic/generous...

Cheers (and a happy 2017),
Andreas

On 30.12.2016 09:43, David Menendez wrote:
> On Fri, Dec 30, 2016 at 2:13 AM, Sven Panne <svenpanne at gmail.com
> <mailto:svenpanne at gmail.com>> wrote:
>
>     2016-12-30 5:50 GMT+01:00 David Menendez <dave at zednenem.com
>     <mailto:dave at zednenem.com>>:
>
>         [...] I don't think making life easy for -Wall clean people
>         should be a goal. The whole point of warnings is that they
>         indicate things that might not be a problem. Otherwise, they’d
>         be errors. This is especially true for warnings that only show
>         up if you use -Wall instead of -W.
>
>
>     This is largely a matter of personal preference, and this is
>     probably even changing over time: 10-20 years ago, I didn't care
>     much about -Wall (in various languages/compilers) too much, but this
>     has changed with experience in tons of projects: Basically each and
>     every warning turned into a bug sooner or later, with very, very few
>     exceptions. So I'm basically a hardcore -Wall-clean-fanatic
>     nowaydays. :-) Not using -Wall doesn't make the problems go away,
>     you only discover them much, much later, probably when your SW is
>     shipped to your client.
>
>     So whatever is done, it should be easily be possible to be
>     -Wall-clean, which basically means more control over warnings.
>     Especially important are one-shot things like the usual C/C++'s
>     NOLINT ("I know what I'm doing here, really!") comments, which make
>     it possible to be extremely fine-grained about warnings.
>
>     Warnings from compilers are just like people crying for help: If you
>     see them too often, you get used to them and ignore them, which in
>     the long run is bad for all parties involved…
>
>
> Why -Wall and not -W? If something is almost always an issue, shouldn’t
> it be in -W?
>
> The point I was trying to make is that we don’t want to prevent compiler
> developers from adding warnings (or library developers from deprecating
> things) merely to make life easier for people who want to be -Wall clean.
>
> Having a syntax to disable a warning is not a bad idea, even though it
> brings to mind the “please” keyword from Intercal.
>
> --
> Dave Menendez <dave at zednenem.com <mailto:dave at zednenem.com>>
> <http://www.eyrie.org/~zednenem/>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/