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

[amindfv at gmail.com]

I don't think there actually will be any need for CPP if we add this to the Prelude. I'm +1 on adding it, either as 'readMay' or 'readMaybe'

Tom


> El 29 dic 2016, a las 07:34, Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk> escribió:
> 
> Hi,
> 
> Yuras Shumovich said:
> 
> > >> 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.
> 
> I can only second this. It is *very* frustrating when code fails
> to compile with an slightly out-of-date version of GHC just because
> someone, perhaps a beginner, perhaps mostly by accident, use a new
> "nifty" add on to the prelude just because it happens to be there.
> 
> I recently had this experience with code written for a recent version
> of GHC I needed to make work with GHC 7.8. I had to make rather a lot
> of edits that ultimately turned out to be entirely trivial, in many cases because new, alternative names had been added for existing
> features. When I compared the "before" and "after" versions of the
> code, I didn't find the new version an iota more readable or elegant
> than the old one on balance because the number of affected lines in
> relative terms was small so the only real effect of the additions I had
> to get rid of was to increase the cognitive burden of the reader in terms of a larger "Prelude vocabulary".
> 
> I wouldn't have minded half as much if the new features had been
> signalled by explicit imports.
> 
> And most likely, in many cases, the new features would not have been
> used at all as they were not particularly important for this particular
> piece of code (in terms of increasing readability etc). Which
> is not to at all to say that these features might not be very
> useful for other pieces of code. In which case they could just have
> just be imported explicitly.
> 
> So indeed, as Yuras said: "We should be careful with the Prelude".
> 
> /Henrik
> 
> 
> 
> 
> 
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it. 
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
> 
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries