Proposal: deprecate Prelude.read - Libraries - Haskell.org

newer
Make Eq type class single method

Proposal: deprecate Prelude.read

older
status of mtl

Fumiaki Kinoshita

14 Oct 2021 14 Oct '21

10:31 p.m.

It is a partial function that does not provide a call stack, and it's very slow too. I propose deprecating 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 can totally ignore warnings. I believe this proposal is not that controversial.

Attachments:

attachment.html (text/html — 619 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

Emily Pillmore

14 Oct 14 Oct

11:16 p.m.

NOPE. On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita < fumiexcel@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@ haskell. org ( Libraries@haskell.org ) http:/ / mail. haskell. org/ cgi-bin/ mailman/ listinfo/ libraries ( http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries )

Reply

Sign in to reply online Use email software

Edward Kmett

11:47 p.m.

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 wrote:

NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita 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@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

Reply

Sign in to reply online Use email software

Carter Schonwald

11:52 p.m.

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 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 wrote:

...
NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita 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@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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Fumiaki Kinoshita

15 Oct 15 Oct

12:27 a.m.

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 :

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 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 wrote:

...
NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita 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@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

_______________________________________________ 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

Reply

Sign in to reply online Use email software

David Feuer

12:37 a.m.

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 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 :

...
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 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 wrote:

...
NOPE.

On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita
...
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@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

_______________________________________________ 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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

David Feuer

14 Oct 14 Oct

11:46 p.m.

If it doesn't give a call stack, we can fix that. While I avoid using it myself, and I think it's much better to use (at least) Text.readMaybe, I'm not convinced that the breakage to existing educational material is worth the benefit of actually removing it. On Thu, Oct 14, 2021 at 10:31 PM Fumiaki Kinoshita wrote:

It is a partial function that does not provide a call stack, and it's very slow too.

I propose deprecating 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 can totally ignore warnings. I believe this proposal is not that controversial. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Henning Thielemann

15 Oct 15 Oct

4:05 a.m.

On Thu, 14 Oct 2021, David Feuer wrote:

If it doesn't give a call stack, we can fix that. While I avoid using it myself, and I think it's much better to use (at least) Text.readMaybe, I'm not convinced that the breakage to existing educational material is worth the benefit of actually removing it.

One can use HLint to flag uses of 'read'.

Reply

Sign in to reply online Use email software

Andreas Abel

4:37 a.m.

+1 to promoting `readMaybe`. HLint could replace `read` by `fromMaybe undefined . readMaybe`. Partiality can be debugged better when it is in the application, rather than in the library. On 2021-10-15 10:05, Henning Thielemann wrote:

On Thu, 14 Oct 2021, David Feuer wrote:

...
If it doesn't give a call stack, we can fix that. While I avoid using it myself, and I think it's much better to use (at least) Text.readMaybe, I'm not convinced that the breakage to existing educational material is worth the benefit of actually removing it.

One can use HLint to flag uses of 'read'. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Reply

Sign in to reply online Use email software

Georgi Lyubenov

5:02 a.m.

I've started up this discussion over at the hlint issue tracker too: https://github.com/ndmitchell/hlint/issues/1307 On Fri, Oct 15, 2021 at 11:39 AM Andreas Abel wrote:

+1 to promoting `readMaybe`.

HLint could replace `read` by `fromMaybe undefined . readMaybe`. Partiality can be debugged better when it is in the application, rather than in the library.

On 2021-10-15 10:05, Henning Thielemann wrote:

...
On Thu, 14 Oct 2021, David Feuer wrote:

...
If it doesn't give a call stack, we can fix that. While I avoid using it myself, and I think it's much better to use (at least) Text.readMaybe, I'm not convinced that the breakage to existing educational material is worth the benefit of actually removing it.

One can use HLint to flag uses of 'read'. _______________________________________________ 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

Reply

Sign in to reply online Use email software

1313

Age (days ago)

1313

Last active (days ago)

Download

9 comments

8 participants

tags

participants (8)

Andreas Abel
Carter Schonwald
David Feuer
Edward Kmett
Emily Pillmore
Fumiaki Kinoshita
Georgi Lyubenov
Henning Thielemann