Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Haskell - Libraries mailing list
read [1] is an easy way to introduce runtime exceptions into programs,
but its documentation doesn't sufficiently warn of this danger. read's
safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
[3], are relatively unknown and too hard to find.

To guide users (particularly newcomers) away from read and towards
readMaybe and readEither, I propose to

1. Add readMaybe to the Prelude
2. Add readEither to the Prelude
3. Change the documentation for read to point out the partiality and
to recommend the above alternatives:

    The haddocks for read currently read:

    > The read function reads input from a string, which must be
completely consumed by the input process.

    I propose to add a paragraph roughly like this:

    > Note: read will throw an error if the parse fails. If there's
any uncertainty w.r.t. the shape of the input, readMaybe or readEither
should be used instead.


Name clashes:

A cursory code search on Github for readMaybe [4] reveals many
existing definitions, mostly with the same type (Read a => String ->
Maybe a) and definition. The same search for readEither [5] shows
mostly GHC forks.

Design issues:

I am somewhat doubtful about the benefit of readEither over readMaybe:
While readEither does give additional info on the kind of parse
failures, that information is encoded in a String error message, from
which it must be parsed if it is needed in the program.


As the different parts of the proposal can be implemented
independently of each other, please vote separately on each part of
the proposal.

Discussion period: 4 weeks.

Cheers,
Simon

[1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read
[2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readMaybe
[3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEither
[4] https://github.com/search?l=Haskell&q=readMaybe&type=Code
[5] https://github.com/search?l=Haskell&q=readEither&type=Code
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ivan Lazar Miljenovic
On 28 December 2016 at 14:58, Simon Jakobi via Libraries
<[hidden email]> wrote:
> read [1] is an easy way to introduce runtime exceptions into programs,
> but its documentation doesn't sufficiently warn of this danger. read's
> safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
> [3], are relatively unknown and too hard to find.
>
> To guide users (particularly newcomers) away from read and towards
> readMaybe and readEither, I propose to
>
> 1. Add readMaybe to the Prelude

+1

> 2. Add readEither to the Prelude

-0.1 (because as you stated in your "Design Issues" section, I doubt
its usefulness).

> 3. Change the documentation for read to point out the partiality and
> to recommend the above alternatives:
>
>     The haddocks for read currently read:
>
>     > The read function reads input from a string, which must be
> completely consumed by the input process.
>
>     I propose to add a paragraph roughly like this:
>
>     > Note: read will throw an error if the parse fails. If there's
> any uncertainty w.r.t. the shape of the input, readMaybe or readEither
> should be used instead.

+1

>
>
> Name clashes:
>
> A cursory code search on Github for readMaybe [4] reveals many
> existing definitions, mostly with the same type (Read a => String ->
> Maybe a) and definition. The same search for readEither [5] shows
> mostly GHC forks.
>
> Design issues:
>
> I am somewhat doubtful about the benefit of readEither over readMaybe:
> While readEither does give additional info on the kind of parse
> failures, that information is encoded in a String error message, from
> which it must be parsed if it is needed in the program.
>
>
> As the different parts of the proposal can be implemented
> independently of each other, please vote separately on each part of
> the proposal.
>
> Discussion period: 4 weeks.
>
> Cheers,
> Simon
>
> [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read
> [2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readMaybe
> [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEither
> [4] https://github.com/search?l=Haskell&q=readMaybe&type=Code
> [5] https://github.com/search?l=Haskell&q=readEither&type=Code
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Feuer
In reply to this post by Haskell - Libraries mailing list
On Dec 27, 2016 10:59 PM, "Simon Jakobi via Libraries" <[hidden email]> wrote:
read [1] is an easy way to introduce runtime exceptions into programs,
but its documentation doesn't sufficiently warn of this danger. read's
safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
[3], are relatively unknown and too hard to find.

A while back I brought up the idea of adding custom warning "classes", allowing such functions to be tagged partial. I should probably put together a proper proposal now that we have that process. Personally, I'd love to remove read from the Prelude, but that would be hard.

1. Add readMaybe to the Prelude

+1

2. Add readEither to the Prelude

+1

3. Change the documentation for read to point out the partiality and
to recommend the above alternatives:

+1 

    > If there's
any uncertainty w.r.t. the shape of the input, readMaybe or readEither
should be used instead.

I would put it more strongly:

read should be applied only to strings that are known to have been produced by methods of the Show class.


Design issues:

I am somewhat doubtful about the benefit of readEither over readMaybe:
While readEither does give additional info on the kind of parse
failures, that information is encoded in a String error message, from
which it must be parsed if it is needed in the program.

It's still the right way to handle error reporting for Read.

Very wrong:

do
  x <- read <$> getInput
  use x

Correct, in some contexts, but extremely lousy:

do
  x <- read <$> getInput
  evaluate (force x)
  use x

Correct, but uninformative:

do
  Just x <- readMaybe <$> getInput
  use x

Correct and informative:

do
  ip <- readEither <$> getInput
  either (throwIO . parseError) use ip
(For some value of parseError)

Or, when reasonable,

do
  ip <- readEither <$> getInput
  either (\m -> displayMessage m *> tryAgain) ip

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Ivan Lazar Miljenovic
On 28 December 2016 at 15:46, David Feuer <[hidden email]> wrote:

> On Dec 27, 2016 10:59 PM, "Simon Jakobi via Libraries"
> <[hidden email]> wrote:
>
> read [1] is an easy way to introduce runtime exceptions into programs,
> but its documentation doesn't sufficiently warn of this danger. read's
> safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
> [3], are relatively unknown and too hard to find.
>
>
> A while back I brought up the idea of adding custom warning "classes",
> allowing such functions to be tagged partial. I should probably put together
> a proper proposal now that we have that process. Personally, I'd love to
> remove read from the Prelude, but that would be hard.
>
>
> 1. Add readMaybe to the Prelude
>
>
> +1
>
> 2. Add readEither to the Prelude
>
>
> +1
>
> 3. Change the documentation for read to point out the partiality and
> to recommend the above alternatives:
>
>
> +1
>
>
>     > If there's
> any uncertainty w.r.t. the shape of the input, readMaybe or readEither
> should be used instead.
>
>
> I would put it more strongly:
>
> read should be applied only to strings that are known to have been produced
> by methods of the Show class.

More so than that: you know that it's for this exact type.

(Though I have [ab]used `read` to convert a String value consisting
solely of digits to an `Int` within a parsing library.)

>
>
>
> Design issues:
>
> I am somewhat doubtful about the benefit of readEither over readMaybe:
> While readEither does give additional info on the kind of parse
> failures, that information is encoded in a String error message, from
> which it must be parsed if it is needed in the program.
>
>
> It's still the right way to handle error reporting for Read.
>
> Very wrong:
>
> do
>   x <- read <$> getInput
>   use x
>
> Correct, in some contexts, but extremely lousy:
>
> do
>   x <- read <$> getInput
>   evaluate (force x)
>   use x
>
> Correct, but uninformative:
>
> do
>   Just x <- readMaybe <$> getInput
>   use x
>
> Correct and informative:
>
> do
>   ip <- readEither <$> getInput
>   either (throwIO . parseError) use ip
> (For some value of parseError)
>
> Or, when reasonable,
>
> do
>   ip <- readEither <$> getInput
>   either (\m -> displayMessage m *> tryAgain) ip

I would argue that if you're doing something like this then you should
really be using a proper combinator parsing library.

--
Ivan Lazar Miljenovic
[hidden email]
http://IvanMiljenovic.wordpress.com
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Haskell - Libraries mailing list
In reply to this post by David Feuer
2016-12-28 5:46 GMT+01:00 David Feuer <[hidden email]>:
> >     > If there's
> > any uncertainty w.r.t. the shape of the input, readMaybe or readEither
> > should be used instead.
>
>
> I would put it more strongly:
>
> read should be applied only to strings that are known to have been produced
> by methods of the Show class.

I agree, that's more clear.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Andrew Martin
In reply to this post by Haskell - Libraries mailing list
1. +1
2. ambivalent, I've never actually seen anyone use readEither, but it doesn't really hurt for it to be there since it isn't stealing anything valuable from the namespace.
3. +1

In my mind, the single most important part of this is part (3), improving the docs. All partial functions defined in base should come with warnings about this in the docs, along with hyperlinks to total functions for accomplishing the same thing.

-Andrew Martin

On Tue, Dec 27, 2016 at 10:58 PM, Simon Jakobi via Libraries <[hidden email]> wrote:
read [1] is an easy way to introduce runtime exceptions into programs,
but its documentation doesn't sufficiently warn of this danger. read's
safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
[3], are relatively unknown and too hard to find.

To guide users (particularly newcomers) away from read and towards
readMaybe and readEither, I propose to

1. Add readMaybe to the Prelude
2. Add readEither to the Prelude
3. Change the documentation for read to point out the partiality and
to recommend the above alternatives:

    The haddocks for read currently read:

    > The read function reads input from a string, which must be
completely consumed by the input process.

    I propose to add a paragraph roughly like this:

    > Note: read will throw an error if the parse fails. If there's
any uncertainty w.r.t. the shape of the input, readMaybe or readEither
should be used instead.


Name clashes:

A cursory code search on Github for readMaybe [4] reveals many
existing definitions, mostly with the same type (Read a => String ->
Maybe a) and definition. The same search for readEither [5] shows
mostly GHC forks.

Design issues:

I am somewhat doubtful about the benefit of readEither over readMaybe:
While readEither does give additional info on the kind of parse
failures, that information is encoded in a String error message, from
which it must be parsed if it is needed in the program.


As the different parts of the proposal can be implemented
independently of each other, please vote separately on each part of
the proposal.

Discussion period: 4 weeks.

Cheers,
Simon

[1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read
[2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readMaybe
[3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEither
[4] https://github.com/search?l=Haskell&q=readMaybe&type=Code
[5] https://github.com/search?l=Haskell&q=readEither&type=Code
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

amindfv
What about other functions from 'safe', eg headMay, atMay, readNote, etc?

Tom


El 28 dic 2016, a las 08:40, Andrew Martin <[hidden email]> escribió:

1. +1
2. ambivalent, I've never actually seen anyone use readEither, but it doesn't really hurt for it to be there since it isn't stealing anything valuable from the namespace.
3. +1

In my mind, the single most important part of this is part (3), improving the docs. All partial functions defined in base should come with warnings about this in the docs, along with hyperlinks to total functions for accomplishing the same thing.

-Andrew Martin

On Tue, Dec 27, 2016 at 10:58 PM, Simon Jakobi via Libraries <[hidden email]> wrote:
read [1] is an easy way to introduce runtime exceptions into programs,
but its documentation doesn't sufficiently warn of this danger. read's
safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
[3], are relatively unknown and too hard to find.

To guide users (particularly newcomers) away from read and towards
readMaybe and readEither, I propose to

1. Add readMaybe to the Prelude
2. Add readEither to the Prelude
3. Change the documentation for read to point out the partiality and
to recommend the above alternatives:

    The haddocks for read currently read:

    > The read function reads input from a string, which must be
completely consumed by the input process.

    I propose to add a paragraph roughly like this:

    > Note: read will throw an error if the parse fails. If there's
any uncertainty w.r.t. the shape of the input, readMaybe or readEither
should be used instead.


Name clashes:

A cursory code search on Github for readMaybe [4] reveals many
existing definitions, mostly with the same type (Read a => String ->
Maybe a) and definition. The same search for readEither [5] shows
mostly GHC forks.

Design issues:

I am somewhat doubtful about the benefit of readEither over readMaybe:
While readEither does give additional info on the kind of parse
failures, that information is encoded in a String error message, from
which it must be parsed if it is needed in the program.


As the different parts of the proposal can be implemented
independently of each other, please vote separately on each part of
the proposal.

Discussion period: 4 weeks.

Cheers,
Simon

[1] http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#v:read
[2] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readMaybe
[3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEither
[4] https://github.com/search?l=Haskell&q=readMaybe&type=Code
[5] https://github.com/search?l=Haskell&q=readEither&type=Code
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



--
-Andrew Thaddeus Martin
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Henning Thielemann
In reply to this post by Haskell - Libraries mailing list

On Wed, 28 Dec 2016, Simon Jakobi via Libraries wrote:

> read [1] is an easy way to introduce runtime exceptions into programs,
> but its documentation doesn't sufficiently warn of this danger. read's
> safe alternatives, Text.Read.readMaybe [2] and Text.Read.readEither
> [3], are relatively unknown and too hard to find.
>
> To guide users (particularly newcomers) away from read and towards
> readMaybe and readEither, I propose to
>
> 1. Add readMaybe to the Prelude
> 2. Add readEither to the Prelude

I do not like to add more stuff to Prelude. It is pretty cumbersome to
write packages that equally work for Prelude versions before and after
this change. In order to avoid preprocessor clutter I tend to import
explicitly from Prelude or other 'base' modules. You can easily import
these functions from Text.Read.

I would be ok with deprecating 'read'.

Generally I think that the Read class is overused. Strictly spoken, it
would be only sensible to parse Haskell expressions with it, but actually
it is mostly used for parsing user input like numbers. But why should a
user enter a number in a Haskell compatible way or even the way, the
current 'show' implementation does?

> 3. Change the documentation for read to point out the partiality and
> to recommend the above alternatives:

I prefer that.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yitzchak Gale
Henning Thielemann wrote:
> I do not like to add more stuff to Prelude. It is pretty cumbersome to write
> packages that equally work for Prelude versions before and after this
> change. In order to avoid preprocessor clutter I tend to import explicitly
> from Prelude or other 'base' modules. You can easily import these functions
> from Text.Read.

That's all true. After an earlier period of continual change to the
Prelude, we have had a period where the Prelude was effectively
frozen, for this reason.

But after some years of a frozen Prelude, many people feel that
we have accumulated cruft, and that now the Prelude needs to
be updated again to match modern practice. A sudden upheaval
doesn't seem prudent, but incremental changes like this one that
give a lot of benefit for little cost seem worthwhile.

> Generally I think that the Read class is overused. Strictly spoken, it would
> be only sensible to parse Haskell expressions with it, but actually it is
> mostly used for parsing user input like numbers.

Nowadays parsing numbers can use the more efficient and
correct combinators in places like Data.Text.Read and
Data.Attoparsec. But there are other common uses of Read
(when performance does not matter), such as:

o Debugging and test suites
o Easy serialization
o An input data file format that parses for free

Regards,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yitzchak Gale
In reply to this post by amindfv
Tom wrote:
> What about other functions from 'safe',
> eg headMay, atMay, readNote, etc?

The standard spelling of "headMay", already included
in base, is "listToMaybe".

In general, once you have readMaybe, NonEmpty, and
the rich set of combinators and instances we have today
for Maybe and Either, the safe library really isn't needed
anymore.

It was a great innovation at the time - it brought the
problem of partial functions to the forefront. But I prefer
using the standard names we have for those functions
nowadays, or occasionally using a simple combination
of two of them. The function names in the safe library
always seemed a bit awkward to me.

YItz
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Henning Thielemann
In reply to this post by Yitzchak Gale

On Wed, 28 Dec 2016, Yitzchak Gale wrote:

> But after some years of a frozen Prelude, many people feel that
> we have accumulated cruft, and that now the Prelude needs to
> be updated again to match modern practice. A sudden upheaval
> doesn't seem prudent, but incremental changes like this one that
> give a lot of benefit for little cost seem worthwhile.

What precisely is the problem of importing readMaybe and readEither from
Text.Read? The current state means you have to import them, that is, you
have to add one import line and this solution works back to GHC-7.6. If we
add readMaybe and readEither to Prelude, 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.

This seems to be too much effort if 'read' calls should be replaced by
other functions anyway.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Haskell - Libraries mailing list
In reply to this post by Henning Thielemann
2016-12-28 17:12 GMT+01:00 Henning Thielemann <[hidden email]>:
> I would be ok with deprecating 'read'.

That seems like a reasonable idea but I would prefer to discuss it in
a separate thread.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Haskell - Libraries mailing list
In reply to this post by Henning Thielemann
2016-12-28 20:41 GMT+01:00 Henning Thielemann <[hidden email]>:
> What precisely is the problem of importing readMaybe and readEither from
> Text.Read?

Those who are aware that these functions reside in Text.Read can of
course import them with little effort.

The point of exporting these functions from the Prelude is to present
them to everyone else, particularly newcomers who might otherwise use
read without being aware of its partiality.

> The current state means you have to import them, that is, you
> have to add one import line and this solution works back to GHC-7.6. If we
> add readMaybe and readEither to Prelude, 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.

> This seems to be too much effort if 'read' calls should be replaced by other
> functions anyway.

I disagree. While Read may not be the right way (TM) to parse numbers,
it currently is the standard way presented to newcomers. I invite you
to google for "haskell parse int string"!

I don't want to discourage anyone from bringing a better solution into
base, but at this point I would like to incrementally improve the
status quo. I think the cost that we impose on package maintainers by
introducing readMaybe (and possibly readEither) into Prelude is
reasonable.

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Yuras Shumovich
On Thu, 2016-12-29 at 03:42 +0100, Simon Jakobi via Libraries wrote:

> 2016-12-28 20:41 GMT+01:00 Henning Thielemann <lemming@henning-thiele
> mann.de>:
> > What precisely is the problem of importing readMaybe and readEither
> > from
> > Text.Read?
>
> Those who are aware that these functions reside in Text.Read can of
> course import them with little effort.
>
> The point of exporting these functions from the Prelude is to present
> them to everyone else, particularly newcomers who might otherwise use
> read without being aware of its partiality.

Documenting partiality of `read` should be enough IMO.

>
> > The current state means you have to import them, that is, you
> > have to add one import line and this solution works back to GHC-
> > 7.6. If we
> > add readMaybe and readEither to Prelude, 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.

>
> > This seems to be too much effort if 'read' calls should be replaced
> > by other
> > functions anyway.
>
> I disagree. While Read may not be the right way (TM) to parse
> numbers,
> it currently is the standard way presented to newcomers. I invite you
> to google for "haskell parse int string"!
>
> I don't want to discourage anyone from bringing a better solution
> into
> base, but at this point I would like to incrementally improve the
> status quo. I think the cost that we impose on package maintainers by
> introducing readMaybe (and possibly readEither) into Prelude is
> reasonable.

Incremental improvements should go in some specific direction,
otherwise they are random steps in the design space. I'm not sure
optimizing for newcomers is a good direction. If the goal is to remove
partial functions from Prelude, then there should be a clear plan where
adding `readMaybe` is just the first step. Without the plan we'll never
do the next step or we'll do it in the opposite direction.

Adding `readMaybe` to Prelude makes it discoverable, but we can't add
every useful function into Prelude. IMO fat Prelude in the reason for
bad discoverability -- if something is not in Prelude, then it doesn't
exist, because Prelude already contains (worse) alternative. To solve
that, we can move everything related to `Read` type class into one
module, e.g. Data.Read, and then `read` and `readMaybe` will have the
same discoverability. If it is the goal, then adding `readMaybe` to
Prelude is a step in wrong direction.

I'm against the proposal (except the documentation part) until it is
presented in wider context.

>
> Cheers,
> Simon
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Henrik Nilsson-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

amindfv
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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, [hidden email] 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bardur Arantsson-2
On 2016-12-29 21:12, Andreas Abel wrote:
>
> I am in favor of deprecating "read" and pointing to a total version in a
> library.  Otherwise, I'd leave the Prelude unchanged.
>

But that throws a wrench in the works of people who want to be "-Wall"
clean... unless you mean "deprecated" in the sense of being *documented*
as deprecated rather than actually marked as such (causing deprecation
warnings during compilation).

I'm not sure actually... do we have fine-grained deprecation warnings
yet?[1] I.e. can we turn on/off individual deprecation warnings with
compiler switches? If so, then just deprecating read and pointing to a
readMaybe in some module might be the optimal solution here.

Regards,

[1] If we don't then I honestly think that this may be the single most
important feature to be able to move forward wrt. the Prelude. (Well, a
"go fix" type tool might be even better, but that's not likely to happen
any time soon.)

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Menendez-2
On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <[hidden email]> wrote:
On 2016-12-29 21:12, Andreas Abel wrote:
>
> I am in favor of deprecating "read" and pointing to a total version in a
> library.  Otherwise, I'd leave the Prelude unchanged.

This is also my preference. If we *have* to change the Prelude, I’d prefer moving Read out entirely.

But that throws a wrench in the works of people who want to be "-Wall"
clean... unless you mean "deprecated" in the sense of being *documented*
as deprecated rather than actually marked as such (causing deprecation
warnings during compilation).

I don't think making life easy for -Wall clean people should be a goal. The whole point of warnings is that they indicate things that might not be a problem. Otherwise, they’d be errors. This is especially true for warnings that only show up if you use -Wall instead of -W.

--

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Edward Kmett-2
In reply to this post by Bardur Arantsson-2
On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson <[hidden email]> wrote:
On 2016-12-29 21:12, Andreas Abel wrote:
>
> I am in favor of deprecating "read" and pointing to a total version in a
> library.  Otherwise, I'd leave the Prelude unchanged.
>

But that throws a wrench in the works of people who want to be "-Wall"
clean... unless you mean "deprecated" in the sense of being *documented*
as deprecated rather than actually marked as such (causing deprecation
warnings during compilation).

Indeed. 

I'm not sure actually... do we have fine-grained deprecation warnings
yet?[1]

We do not. There has been some work on breaking up the monolithic set of warnings and being a bit more regular about how we handle them, but not individual groups of deprecations.
 
I.e. can we turn on/off individual deprecation warnings with
compiler switches? If so, then just deprecating read and pointing to a
readMaybe in some module might be the optimal solution here.
 
I'm strongly -1 on adding a full-fledged DEPRECATED flag to read. The amount of noise that would generate would dwarf anything else under discussion by multiple orders of magnitude. It is in the Haskell Report and it has been used a lot for a couple of decades now.

On the other hand, whether or not anything changes in Prelude, I'm a strong +1 on adding documentation to it that mentions these safer alternatives, and where to get them if necessary.

[1] If we don't then I honestly think that this may be the single most
important feature to be able to move forward wrt. the Prelude. (Well, a
"go fix" type tool might be even better, but that's not likely to happen
any time soon.)

The amount of CPP running around in Haskell with any sort of long support window makes 'go fix' tools quite shockingly difficult for us to get right.

I'm a weak +1 on adding re-export of the existing readMaybe and readEither to the Prelude, possibly after a warning period. They are sufficiently obscure names that I'm personally not expecting many name conflicts at all and the changes in base are minimal as the classes and 'read' are already re-exports from the same place, so there isn't much of an engineering challenge.

I do think if we're going to include readMaybe there isn't much point in not including the slightly more powerful readEither.

-Edward

 
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
123
Loading...