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

I am in favor of deprecating "read" and pointing to a total version in a library. Otherwise, I'd leave the Prelude unchanged. --Andreas On 29.12.2016 21:17, amindfv@gmail.com wrote:

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

---

Libraries mailing list Libraries@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@gu.se http://www2.tcs.ifi.lmu.de/~abel/