Proposal: deprecate Prelude.read

[Fumiaki Kinoshita]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211015/ce5bf656/attachment.html>