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

[Andreas Abel]

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 at 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 <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
> _______________________________________________
> 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/