Proposal: deprecate Prelude.read

[David Feuer]

readEither is kind of a lie. The Read parsing system has no real error
handling, so readEither just confuses people into thinking they're getting
a useful message when they're not.

On Fri, Oct 15, 2021 at 12:28 AM Fumiaki Kinoshita <fumiexcel at gmail.com>
wrote:

> I'm not proposing to *remove* it; my suggestion is to attach a warning
> perpetually (or like 20 years).
> Without warnings, I think just adding readMaybe would have little
> incentive to the ecosystem;
> we can't expect people to eyeball the uses of read (highly generic name)
> in their codebase.
> We've broken a lot of code using fail simply because there was no warning
> enabled by default.
>
> To be clear I'm all for bringing readMaybe and readEither (I prefer the
> either variant because of the Nothing blindness) into Prelude.
> Once that happens, IMO DEPRECATE pragma should be added to encourage
> switching to safer variants.
>
> 2021年10月15日(金) 12:53 Carter Schonwald <carter.schonwald at gmail.com>:
>
>> I agree with emily david and ed
>>
>> Bringing readMaybe into prelude plus adding call stack info to read are
>> the Sane path forward to improving Haskell.
>>
>>  Deprecating read, insofar as how ghc deprecation works, is a lotta pain
>> for no real hao.
>>
>> On Thu, Oct 14, 2021 at 11:47 PM Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> A variant of this that I would support would be to bring readMaybe into
>>> Prelude from Text.Read for a good long time, and *then* to deprecate
>>> read. As it stands, read and the almost equally ugly readIO are the
>>> only Prelude facing ways for a user to really consume a Read instance,
>>> so losing read there is a heck of a blow to usability without a
>>> replacement being in place with an established pattern of usage.
>>>
>>> -Edward
>>>
>>> On Thu, Oct 14, 2021 at 11:16 PM Emily Pillmore <emilypi at cohomolo.gy>
>>> wrote:
>>>
>>>> NOPE.
>>>>
>>>>
>>>> On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <fumiexcel at gmail.com
>>>> > wrote:
>>>>
>>>>> It is a partial function that does not provide a call stack, and it's
>>>>> very slow too.
>>>>>
>>>>> I propose deprecating Prelude.read <http://prelude.read/>. Adding
>>>>> deprecation should not break anything substantial because Hackage rejects
>>>>> -Werror (application code using -Werror is likely to experience a lot more
>>>>> breakage anyway, and I'd say it's their fault if it fails to build due to a
>>>>> use of read along with -Werror).
>>>>>
>>>>> Of course those who still want to use Prelude.read
>>>>> <http://prelude.read/> can totally ignore warnings. I believe this
>>>>> proposal is not that controversial.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/20211015/520bbddb/attachment.html>