Re: Proposal: deprecate Prelude.read
Edward Kmett <[email protected]> Thu, 14 Oct 2021 23:47:07 -0400
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <CAJumaK9g=G2F0pow9Eo=s1-nfcGe1=oq6CeBKv8X_EZeCyvmnw@mail.gmail.com> |
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 <[email protected]> wrote: > NOPE. > > > On Thu, Oct 14, 2021 at 8:31 PM, Fumiaki Kinoshita <[email protected]> > 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 >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries