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

older
Proposal: Add splitL and splitR to...

Simon Jakobi

27 Dec 2016 27 Dec '16

10:58 p.m.

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:readMa... [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEi... [4] https://github.com/search?l=Haskell&q=readMaybe&type=Code [5] https://github.com/search?l=Haskell&q=readEither&type=Code

Show replies by date

Ivan Lazar Miljenovic

27 Dec 27 Dec

11:09 p.m.

On 28 December 2016 at 14:58, 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

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

...

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:readMa... [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEi... [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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

David Feuer

11:46 p.m.

On Dec 27, 2016 10:59 PM, "Simon Jakobi via Libraries" < libraries@haskell.org> 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

Ivan Lazar Miljenovic

11:56 p.m.

On 28 December 2016 at 15:46, David Feuer wrote:

...

On Dec 27, 2016 10:59 PM, "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.

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 Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Simon Jakobi

28 Dec 28 Dec

2:47 a.m.

2016-12-28 5:46 GMT+01:00 David Feuer :

...

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

Andrew Martin

9:40 a.m.

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 < libraries@haskell.org> 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- -Andrew Thaddeus Martin

amindfv＠gmail.com

11:36 a.m.

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

...

El 28 dic 2016, a las 08:40, Andrew Martin 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 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:readMa... [3] http://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html#v:readEi... [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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Yitzchak Gale

2:29 p.m.

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

Henning Thielemann

11:12 a.m.

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.

Yitzchak Gale

2:29 p.m.

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

Henning Thielemann

2:41 p.m.

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.

Simon Jakobi

9:42 p.m.

2016-12-28 20:41 GMT+01:00 Henning Thielemann :

...

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

Yuras Shumovich

29 Dec 29 Dec

6:32 a.m.

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

...

2016-12-28 20:41 GMT+01:00 Henning Thielemann :

...
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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Henrik Nilsson

8:34 a.m.

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.

amindfv＠gmail.com

3:17 p.m.

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 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andreas Abel

3:12 p.m.

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, amindfv@gmail.com 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 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 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

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Bardur Arantsson

4:47 p.m.

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.)

David Menendez

11:50 p.m.

On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson 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. -- Dave Menendez http://www.eyrie.org/~zednenem/

Edward Kmett

11:56 p.m.

Read is one of very few classes with stated a deriving technique in the Haskell Report. Moving it out of the Prelude would break a ridiculous amount of code and involve adding import Text.Read as boilerplate to the top of every single module of Haskell source code out there that deigned to include deriving (Read,....) among the list of instances derived for their data types. The cure feels a lot worse than any disease. Heck, read isn't even a member of the class, so this would just spite users and not even address the symptom raised by this thread. -Edward On Thu, Dec 29, 2016 at 11:50 PM, David Menendez wrote:

...

On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson 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.

-- Dave Menendez http://www.eyrie.org/~zednenem/

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

Sven Panne

30 Dec 30 Dec

2:13 a.m.

2016-12-30 5:50 GMT+01:00 David Menendez :

...

[...] 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.

This is largely a matter of personal preference, and this is probably even changing over time: 10-20 years ago, I didn't care much about -Wall (in various languages/compilers) too much, but this has changed with experience in tons of projects: Basically each and every warning turned into a bug sooner or later, with very, very few exceptions. So I'm basically a hardcore -Wall-clean-fanatic nowaydays. :-) Not using -Wall doesn't make the problems go away, you only discover them much, much later, probably when your SW is shipped to your client. So whatever is done, it should be easily be possible to be -Wall-clean, which basically means more control over warnings. Especially important are one-shot things like the usual C/C++'s NOLINT ("I know what I'm doing here, really!") comments, which make it possible to be extremely fine-grained about warnings. Warnings from compilers are just like people crying for help: If you see them too often, you get used to them and ignore them, which in the long run is bad for all parties involved...

David Menendez

3:43 a.m.

On Fri, Dec 30, 2016 at 2:13 AM, Sven Panne wrote:

...

2016-12-30 5:50 GMT+01:00 David Menendez :

...
[...] 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.

This is largely a matter of personal preference, and this is probably even changing over time: 10-20 years ago, I didn't care much about -Wall (in various languages/compilers) too much, but this has changed with experience in tons of projects: Basically each and every warning turned into a bug sooner or later, with very, very few exceptions. So I'm basically a hardcore -Wall-clean-fanatic nowaydays. :-) Not using -Wall doesn't make the problems go away, you only discover them much, much later, probably when your SW is shipped to your client.

So whatever is done, it should be easily be possible to be -Wall-clean, which basically means more control over warnings. Especially important are one-shot things like the usual C/C++'s NOLINT ("I know what I'm doing here, really!") comments, which make it possible to be extremely fine-grained about warnings.

Warnings from compilers are just like people crying for help: If you see them too often, you get used to them and ignore them, which in the long run is bad for all parties involved…

Why -Wall and not -W? If something is almost always an issue, shouldn’t it be in -W? The point I was trying to make is that we don’t want to prevent compiler developers from adding warnings (or library developers from deprecating things) merely to make life easier for people who want to be -Wall clean. Having a syntax to disable a warning is not a bad idea, even though it brings to mind the “please” keyword from Intercal. -- Dave Menendez http://www.eyrie.org/~zednenem/

Andreas Abel

3:55 a.m.

When updating the documentation for Read, one can at the same time stress that this class is for parsing values in *Haskell* syntax. Same for Show, it should be stressed that it is for printing values into their *Haskell* linearization. I'd guess "Show" is the most abused type class. (Our own code base, Agda, is a prime example for this.) Currently we have: https://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Show.html Converting values to readable strings: the Show class and associated functions. https://hackage.haskell.org/package/base-4.9.0.0/docs/Text-Read.html Converting strings to values. This description is way too generic/generous... Cheers (and a happy 2017), Andreas On 30.12.2016 09:43, David Menendez wrote:

...

On Fri, Dec 30, 2016 at 2:13 AM, Sven Panne mailto:svenpanne@gmail.com> wrote:

2016-12-30 5:50 GMT+01:00 David Menendez mailto:dave@zednenem.com>:

[...] 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.

This is largely a matter of personal preference, and this is probably even changing over time: 10-20 years ago, I didn't care much about -Wall (in various languages/compilers) too much, but this has changed with experience in tons of projects: Basically each and every warning turned into a bug sooner or later, with very, very few exceptions. So I'm basically a hardcore -Wall-clean-fanatic nowaydays. :-) Not using -Wall doesn't make the problems go away, you only discover them much, much later, probably when your SW is shipped to your client.

So whatever is done, it should be easily be possible to be -Wall-clean, which basically means more control over warnings. Especially important are one-shot things like the usual C/C++'s NOLINT ("I know what I'm doing here, really!") comments, which make it possible to be extremely fine-grained about warnings.

Warnings from compilers are just like people crying for help: If you see them too often, you get used to them and ignore them, which in the long run is bad for all parties involved…

Why -Wall and not -W? If something is almost always an issue, shouldn’t it be in -W?

The point I was trying to make is that we don’t want to prevent compiler developers from adding warnings (or library developers from deprecating things) merely to make life easier for people who want to be -Wall clean.

Having a syntax to disable a warning is not a bad idea, even though it brings to mind the “please” keyword from Intercal.

-- Dave Menendez mailto:dave@zednenem.com> http://www.eyrie.org/~zednenem/

_______________________________________________ Libraries mailing list Libraries@haskell.org 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 andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

Henning Thielemann

3 Jan 3 Jan

9:06 a.m.

On Fri, 30 Dec 2016, Andreas Abel wrote:

...

When updating the documentation for Read, one can at the same time stress that this class is for parsing values in *Haskell* syntax. Same for Show, it should be stressed that it is for printing values into their *Haskell* linearization.

I'd guess "Show" is the most abused type class. (Our own code base, Agda, is a prime example for this.)

my concerns, too

Sven Panne

30 Dec 30 Dec

4:01 a.m.

2016-12-30 9:43 GMT+01:00 David Menendez :

...

Why -Wall and not -W? If something is almost always an issue, shouldn’t it be in -W?

My point basically is: The distinction between -Wall and -W is an illusion.

...

The point I was trying to make is that we don’t want to prevent compiler developers from adding warnings (or library developers from deprecating things) merely to make life easier for people who want to be -Wall clean.

Who is "we"? :-) Adding a new sensible warning to the compiler is completely OK, if it breaks some projects, these should be fixed. Deprecating things is OK, too, at least if there is a sane migration path. But of course in both cases, the potential benefits should outweigh the induced costs.

...

Having a syntax to disable a warning is not a bad idea, even though it brings to mind the “please” keyword from Intercal.

:-D The point about such syntax is: Tools almost always give some false positives, so there must be some kind of escape hatch for the programmer to shut them up locally. People who have tried e.g. include-what-you-use, clang-tidy or cppcheck on larger projects probably know what I mean: You can't wait months or even years until a tool is fixed, but you don't want to use a big hammer to silence them, either.

Edward Kmett

29 Dec 29 Dec

11:51 p.m.

On Thu, Dec 29, 2016 at 4:47 PM, Bardur Arantsson 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 Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Simon Jakobi

2 Jan 2 Jan

10:10 a.m.

2016-12-30 5:51 GMT+01:00 Edward Kmett :

...

I'm a weak +1 on adding re-export of the existing readMaybe and readEither to the Prelude, possibly after a warning period.

What would such a warning period look like? Does it simply mean that there is an announcement on the Haskell mailing lists "Heads up, we'll add readMaybe and readEither to the Prelude in base-4.11"?

...

They are sufficiently obscure names that I'm personally not expecting many name conflicts at all

There are quite a few packages [1] that define their private version of readMaybe, but I don't think that these should be counted as arguments _against_ adding the function to Prelude. Simon [1] https://github.com/search?l=Haskell&q=readMaybe&type=Code

Edward Kmett

3 Jan 3 Jan

7:51 a.m.

...

From the discussion so far, feedback seems overwhelmingly positive on making the change, so everything I say here just assumes we're going forward.

The way I see it there are two rough options: Option 1.) We could just add them directly in the next major release. The downside is that then there is no warning period for folks to deal with any (unlikely as they might be) name collisions. On the other hand, such collisions are going to be readily obvious as to how to fix. Option 2.) Or we could go with making the next major GHC release have a warning about those names and the following major release have the Prelude change. This would fit with the behavior of the AMP towards most names, and fit with the behavior of the existing CLC changes that we have in progress over the next few years. The downside is that this then requires someone to hack up some code in GHC to issue the warning about pending names. Given the relative obscurity of the names here I'm less worried about this than I'd otherwise be but embracing the AMP-like approach for consistency might calm some fears of rampant Prelude-changes. By "next GHC release" I'm being a bit vague, because if we went with Option 2 it'd be down to how quickly that code could get written and if GHC HQ wants to make such changes for 8.2 at this time. We're getting close to release candidate time, but on the other hand, it is a pretty straightforward change. This gives a time table of somewhere between the extremes of doing it in 8.2 next month, assuming we decide to just rip the bandaid off and merge, and 8.6 if we don't get warnings in for 8.2 and have to warn in 8.4 and take the names in 8.6. Off the cuff I don't particularly care which way we proceed and I am very much open to feedback about which way we should jump. -Edward On Mon, Jan 2, 2017 at 10:10 AM, Simon Jakobi wrote:

...

2016-12-30 5:51 GMT+01:00 Edward Kmett :

...
I'm a weak +1 on adding re-export of the existing readMaybe and readEither to the Prelude, possibly after a warning period.

What would such a warning period look like? Does it simply mean that there is an announcement on the Haskell mailing lists "Heads up, we'll add readMaybe and readEither to the Prelude in base-4.11"?

...
They are sufficiently obscure names that I'm personally not expecting many name conflicts at all

There are quite a few packages [1] that define their private version of readMaybe, but I don't think that these should be counted as arguments _against_ adding the function to Prelude.

Simon

[1] https://github.com/search?l=Haskell&q=readMaybe&type=Code

Henning Thielemann

9:11 a.m.

On Tue, 3 Jan 2017, Edward Kmett wrote:

...

From the discussion so far, feedback seems overwhelmingly positive on making the change, so everything I say here just assumes we're going forward.

I do not understand the feedback this way. There were strong arguments against adding and I thought that we do not simply count votes.

David Feuer

9:17 a.m.

While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it. On Jan 3, 2017 9:12 AM, "Henning Thielemann" wrote:

...

On Tue, 3 Jan 2017, Edward Kmett wrote:

From the discussion so far, feedback seems overwhelmingly positive on

...
making the change, so everything I say here just assumes we're going forward.

I do not understand the feedback this way. There were strong arguments against adding and I thought that we do not simply count votes. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Mario Blažević

1:40 p.m.

On 2017-01-03 09:17 AM, David Feuer wrote:

...

While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

Tom Murphy

3:26 p.m.

I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude. Tom On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević wrote:

...

On 2017-01-03 09:17 AM, David Feuer wrote:

...
While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

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

Henning Thielemann

3:32 p.m.

On Tue, 3 Jan 2017, Tom Murphy wrote:

...

I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude.

The total replacement in Prelude is reads, the convenient replacement is Text.Read.readMaybe.

Artyom

4:38 p.m.

I'm +1 on improving the documentation of `read`. The current description (“which must be completely consumed by the input process”) is pretty bad. I'm +0.5 on adding `readMaybe` and `readEither` to Prelude. I'm -1 on actually deprecating `read`, even if we do provide a safe replacement in the Prelude. <rant> While removing partial functions aids safety, it also makes the language burdensome and unpleasant to use. Sure, for experienced programmers it might not matter – they have much bigger challenges to overcome, and adding some imports or handling an error takes much less time than debugging a program that is failing because someone else used a partial function somewhere in the middle of code. However, not everyone is an experienced programmer and not everyone is solving Real-World Problems with Haskell. Some people just want to have fun when they are programming, and maybe get something useful as a result. In my experience, nothing kills fun better than having to unwrap and chain Maybes, add dozens of imports, insert `error`s and so on whenever you don't care about failure, etc etc etc. If Haskell gains reputation as an incredibly safe language, yeahwe'll likely see lots of beginners who would want to learn and use Haskell anyway even if it's not that fun; and if we as a community decided to go this way, I would've voted differently, as I would've evaluated the proposal from a different point of view (“whether or not it makes the language safer”). However, as long as we all *haven't* agreed that safety is more important than fun, I'm going to optimise for an outcome which I personally prefer, and leave the “safety above all else” goal to other languages. My personally preferred outcome – i.e. what I want Haskell to be – is a language that is fun to use while still being *possible* to make safe if needed. Thus, I'm glad that newtypes exist and can be used without that much effort. I'm glad that alternative preludes that ban partial functions could be written. I'm glad that qualified imports exist, and I also think it would be good if there was a GHC flag banning unqualified imports. I'm glad that phantom types, type families, etc all exist and are helping people write safe code that they wouldn't be able to write otherwise. Howevev, what I feel really strongly about is that such things should not be the default. It's good that a professional Haskeller (or a team of Haskellers, or a Haskell shop, etc) can enforce safety standards if they want to, and it's good that with Haskell it's easier than with other languages, but why should those standards be forced on *all* Haskellers? Contrary to what some might believe, safety is not an ultimate goal of every Haskeller (an example being myself). I'm fine with my code failing every now and then, because the alternative is that it might not get written at all as I get tired of fighting the compiler and the Prelude. If my preferences are deemed bad/invalid/perverse by the community, or if I'm simply an outlier (as we might determine by doing a survey), or if it turns out that nobody else out there hates handling error cases manually and unwrapping Maybes, then sure, let's deprecate all partial functions. However, if I'm not an outlier, then I'd rather see Haskell move in such a direction that makes it easier for hobbyists to write code *and* easier for professionals to write *safe* code. Deprecating `read` is a move in the opposite direction – it makes hobbyists' lives harder while not changing anything for professionals (because half of them probably uses an in-house or alternative Prelude and another half can just grep for calls to `read` during the continuous integration build). </rant> On 01/03/2017 11:26 PM, Tom Murphy wrote:

...

I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude.

Tom

On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević mailto:mblazevic@stilo.com> wrote:

On 2017-01-03 09:17 AM, David Feuer wrote:

While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

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

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

Henning Thielemann

4:51 p.m.

On Wed, 4 Jan 2017, Artyom wrote:

...

However, not everyone is an experienced programmer and not everyone is solving Real-World Problems with Haskell. Some people just want to have fun when they are programming, and maybe get something useful as a result. In my experience, nothing kills fun better than having to unwrap and chain Maybes, add dozens of imports, insert `error`s and so on whenever you don't care about failure, etc etc etc.

You could just ignore the deprecation warnings like you ignore type defaulting warnings for numbers in GHCi.

...

I'm glad that qualified imports exist, and I also think it would be good if there was a GHC flag banning unqualified imports.

There is -fwarn-missing-import-lists. https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/using-warning...

Theodore Lief Gannon

5:37 p.m.

I consider it a massive failing of Haskell's communal pedagogy that you're unwrapping Maybe often enough that it feels burdensome. That's what fmap is for. I'm not being flip, here. This came up just yesterday on reddit -- in presenting a solution to a problem, fromJust was used, along with a disclaimer about how it's unsafe and only there to avoid complicating the example with error handling. I responded with a version that fmap'd over the Maybe instead of unwrapping it at all: it was a hair shorter, and no more complex. I knew I *could* fmap over Maybe after my first functor tutorial, but connecting the dots to realize that it's what I *should* do wherever it's an option took me a lot longer than it should have, and I'm clearly not alone in that. This is a damn shame, because it represents the difference between wrestling with types to get the benefits of safety vs. breezing along with the top down in your sexy typesafemobile. [1] https://redd.it/5lj45c On Jan 3, 2017 1:40 PM, "Artyom" wrote:

...

I'm +1 on improving the documentation of `read`. The current description (“which must be completely consumed by the input process”) is pretty bad.

I'm +0.5 on adding `readMaybe` and `readEither` to Prelude.

I'm -1 on actually deprecating `read`, even if we do provide a safe replacement in the Prelude.

<rant>

While removing partial functions aids safety, it also makes the language burdensome and unpleasant to use. Sure, for experienced programmers it might not matter – they have much bigger challenges to overcome, and adding some imports or handling an error takes much less time than debugging a program that is failing because someone else used a partial function somewhere in the middle of code.

However, not everyone is an experienced programmer and not everyone is solving Real-World Problems with Haskell. Some people just want to have fun when they are programming, and maybe get something useful as a result. In my experience, nothing kills fun better than having to unwrap and chain Maybes, add dozens of imports, insert `error`s and so on whenever you don't care about failure, etc etc etc.

If Haskell gains reputation as an incredibly safe language, yeahwe'll likely see lots of beginners who would want to learn and use Haskell anyway even if it's not that fun; and if we as a community decided to go this way, I would've voted differently, as I would've evaluated the proposal from a different point of view (“whether or not it makes the language safer”). However, as long as we all *haven't* agreed that safety is more important than fun, I'm going to optimise for an outcome which I personally prefer, and leave the “safety above all else” goal to other languages.

My personally preferred outcome – i.e. what I want Haskell to be – is a language that is fun to use while still being *possible* to make safe if needed. Thus, I'm glad that newtypes exist and can be used without that much effort. I'm glad that alternative preludes that ban partial functions could be written. I'm glad that qualified imports exist, and I also think it would be good if there was a GHC flag banning unqualified imports. I'm glad that phantom types, type families, etc all exist and are helping people write safe code that they wouldn't be able to write otherwise.

Howevev, what I feel really strongly about is that such things should not be the default. It's good that a professional Haskeller (or a team of Haskellers, or a Haskell shop, etc) can enforce safety standards if they want to, and it's good that with Haskell it's easier than with other languages, but why should those standards be forced on *all* Haskellers? Contrary to what some might believe, safety is not an ultimate goal of every Haskeller (an example being myself). I'm fine with my code failing every now and then, because the alternative is that it might not get written at all as I get tired of fighting the compiler and the Prelude.

If my preferences are deemed bad/invalid/perverse by the community, or if I'm simply an outlier (as we might determine by doing a survey), or if it turns out that nobody else out there hates handling error cases manually and unwrapping Maybes, then sure, let's deprecate all partial functions. However, if I'm not an outlier, then I'd rather see Haskell move in such a direction that makes it easier for hobbyists to write code *and* easier for professionals to write *safe* code. Deprecating `read` is a move in the opposite direction – it makes hobbyists' lives harder while not changing anything for professionals (because half of them probably uses an in-house or alternative Prelude and another half can just grep for calls to `read` during the continuous integration build).

</rant> On 01/03/2017 11:26 PM, Tom Murphy wrote:

I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude.

Tom

On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević wrote:

...
On 2017-01-03 09:17 AM, David Feuer wrote:

...
While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

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

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

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

Artyom

5:59 p.m.

I know about fmap :) And, sure, I agree that better pedagogy (and careful library design) can make typesafe programming pleasant in some cases – but not all, and not even enough to make me stop worrying about the rest of them. (I've been using Haskell for eight years by now and I can't call the experience “breezing along with the top down in your sexy typesafemobile”, not really.) On 01/04/2017 01:37 AM, Theodore Lief Gannon wrote:

...

I consider it a massive failing of Haskell's communal pedagogy that you're unwrapping Maybe often enough that it feels burdensome. That's what fmap is for.

I'm not being flip, here. This came up just yesterday on reddit -- in presenting a solution to a problem, fromJust was used, along with a disclaimer about how it's unsafe and only there to avoid complicating the example with error handling. I responded with a version that fmap'd over the Maybe instead of unwrapping it at all: it was a hair shorter, and no more complex.

I knew I *could* fmap over Maybe after my first functor tutorial, but connecting the dots to realize that it's what I *should* do wherever it's an option took me a lot longer than it should have, and I'm clearly not alone in that. This is a damn shame, because it represents the difference between wrestling with types to get the benefits of safety vs. breezing along with the top down in your sexy typesafemobile.

[1] https://redd.it/5lj45c

On Jan 3, 2017 1:40 PM, "Artyom" mailto:yom@artyom.me> wrote:

I'm +1 on improving the documentation of `read`. The current description (“which must be completely consumed by the input process”) is pretty bad.

I'm +0.5 on adding `readMaybe` and `readEither` to Prelude.

I'm -1 on actually deprecating `read`, even if we do provide a safe replacement in the Prelude.

<rant>

While removing partial functions aids safety, it also makes the language burdensome and unpleasant to use. Sure, for experienced programmers it might not matter – they have much bigger challenges to overcome, and adding some imports or handling an error takes much less time than debugging a program that is failing because someone else used a partial function somewhere in the middle of code.

However, not everyone is an experienced programmer and not everyone is solving Real-World Problems with Haskell. Some people just want to have fun when they are programming, and maybe get something useful as a result. In my experience, nothing kills fun better than having to unwrap and chain Maybes, add dozens of imports, insert `error`s and so on whenever you don't care about failure, etc etc etc.

If Haskell gains reputation as an incredibly safe language, yeahwe'll likely see lots of beginners who would want to learn and use Haskell anyway even if it's not that fun; and if we as a community decided to go this way, I would've voted differently, as I would've evaluated the proposal from a different point of view (“whether or not it makes the language safer”). However, as long as we all *haven't* agreed that safety is more important than fun, I'm going to optimise for an outcome which I personally prefer, and leave the “safety above all else” goal to other languages.

My personally preferred outcome – i.e. what I want Haskell to be – is a language that is fun to use while still being *possible* to make safe if needed. Thus, I'm glad that newtypes exist and can be used without that much effort. I'm glad that alternative preludes that ban partial functions could be written. I'm glad that qualified imports exist, and I also think it would be good if there was a GHC flag banning unqualified imports. I'm glad that phantom types, type families, etc all exist and are helping people write safe code that they wouldn't be able to write otherwise.

Howevev, what I feel really strongly about is that such things should not be the default. It's good that a professional Haskeller (or a team of Haskellers, or a Haskell shop, etc) can enforce safety standards if they want to, and it's good that with Haskell it's easier than with other languages, but why should those standards be forced on *all* Haskellers? Contrary to what some might believe, safety is not an ultimate goal of every Haskeller (an example being myself). I'm fine with my code failing every now and then, because the alternative is that it might not get written at all as I get tired of fighting the compiler and the Prelude.

If my preferences are deemed bad/invalid/perverse by the community, or if I'm simply an outlier (as we might determine by doing a survey), or if it turns out that nobody else out there hates handling error cases manually and unwrapping Maybes, then sure, let's deprecate all partial functions. However, if I'm not an outlier, then I'd rather see Haskell move in such a direction that makes it easier for hobbyists to write code *and* easier for professionals to write *safe* code. Deprecating `read` is a move in the opposite direction – it makes hobbyists' lives harder while not changing anything for professionals (because half of them probably uses an in-house or alternative Prelude and another half can just grep for calls to `read` during the continuous integration build).

</rant>

On 01/03/2017 11:26 PM, Tom Murphy wrote:

...
I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude.

Tom

On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević mailto:mblazevic@stilo.com> wrote:

On 2017-01-03 09:17 AM, David Feuer wrote:

While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

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

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

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

David Menendez

10:59 p.m.

On Tue, Jan 3, 2017 at 4:38 PM, Artyom wrote:

...

Deprecating `read` is a move in the opposite direction – it makes hobbyists' lives harder while not changing anything for professionals (because half of them probably uses an in-house or alternative Prelude and another half can just grep for calls to `read` during the continuous integration build).

Do a lot of hobbyists use read? I’m honestly curious: I keep being told that Read is only useful for parsing the output of Show, but I can’t imagine that comes up a lot. I guess I could see being useful for minimal-effort persistence, but parsers with no capacity for error messages make me uncomfortable. In any case, I think there are a couple of different conversations here. The proposal is about adding readMaybe and changing the documentation of read. People brought up deprecation or removal of read, but I don’t think those were actually proposed. -- Dave Menendez http://www.eyrie.org/~zednenem/

Simon Jakobi

4 Jan 4 Jan

2:19 a.m.

2017-01-04 4:59 GMT+01:00 David Menendez :

...

...
Do a lot of hobbyists use read? I’m honestly curious: I keep being told that Read is only useful for parsing the output of Show, but I can’t imagine that comes up a lot. I guess I could see being useful for minimal-effort persistence, but parsers with no capacity for error messages make me uncomfortable.

I believe that read is often used in Project Euler-style problems and programming challenges in order to parse numbers from input files.

Ben Franksen

25 Feb 25 Feb

9:12 a.m.

Am 04.01.2017 um 04:59 schrieb David Menendez:

...

On Tue, Jan 3, 2017 at 4:38 PM, Artyom wrote:

...
Deprecating `read` is a move in the opposite direction – it makes hobbyists' lives harder while not changing anything for professionals (because half of them probably uses an in-house or alternative Prelude and another half can just grep for calls to `read` during the continuous integration build).

Do a lot of hobbyists use read? I’m honestly curious: I keep being told that Read is only useful for parsing the output of Show, but I can’t imagine that comes up a lot. I guess I could see being useful for minimal-effort persistence, but parsers with no capacity for error messages make me uncomfortable.

I use it for numbers, mostly, typically command line arguments. Parsing number is not trivial for floats (or decmal/hex/octal/etc). Cheers Ben

Andrew Butterfield

4 Jan 4 Jan

6:06 a.m.

...

On 3 Jan 2017, at 21:38, Artyom wrote:

...

My personally preferred outcome – i.e. what I want Haskell to be – is a language that is fun to use while still being *possible* to make safe if needed. Thus, I'm glad that newtypes exist and can be used without that much effort. I'm glad that alternative preludes that ban partial functions could be written. I'm glad that qualified imports exist, and I also think it would be good if there was a GHC flag banning unqualified imports. I'm glad that phantom types, type families, etc all exist and are helping people write safe code that they wouldn't be able to write otherwise.

Howevev, what I feel really strongly about is that such things should not be the default. It's good that a professional Haskeller (or a team of Haskellers, or a Haskell shop, etc) can enforce safety standards if they want to, and it's good that with Haskell it's easier than with other languages, but why should those standards be forced on *all* Haskellers? Contrary to what some might believe, safety is not an ultimate goal of every Haskeller (an example being myself). I'm fine with my code failing every now and then, because the alternative is that it might not get written at all as I get tired of fighting the compiler and the Prelude.

I couldn't agree more. Ironically my main research area is that of formal methods and formal semantics, for techniques to prove software (and system) correctness. I have written a number of Haskell programs to assist me - including a GUI-based equational reason theorem prover [1] and a form of "rapid theory prototyping" calculator [2]. For the former correctness is very important, but not the latter. The problem I have to solve is that of "debugging" semantic theories that I develop - as John Rushby of SRI said back in '93: "95% of theorems are false". The rapid theory calculator has proved crucial to my recent work, where testing the theory by calculation was rapidly becoming intractable. However developing the calculator itself was only itself feasible because I could play fast and loose with my code. Just like Artyom, if I had had to fight the compiler and Prelude, I would have lost the will to live.... Perhaps I'm an outlier too ? ;-) [1] https://arxiv.org/abs/1410.8216v1 https://arxiv.org/abs/1410.8216v1 [2] https://www.scss.tcd.ie/andrew.butterfield/DRAFTS/preprints/UTPCalc-UTP2016-... https://www.scss.tcd.ie/andrew.butterfield/DRAFTS/preprints/UTPCalc-UTP2016-... (to appear in LNCS 10134, Feb 2017 Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland

Artyom

3 Jan 3 Jan

4:40 p.m.

...

I'm -1 on deprecating read if we don't provide a safe replacement in the Prelude.

Tom

On Tue, Jan 3, 2017 at 1:40 PM, Mario Blažević mailto:mblazevic@stilo.com> wrote:

On 2017-01-03 09:17 AM, David Feuer wrote:

While I don't often agree with Henning, it seems that the notion of (quasi?)deprecating read is somewhat more popular than the notion of adding replacements for it.

I haven't spoken so far, but that's also my impression and my preference as well.

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

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

Simon Jakobi

9:22 a.m.

2017-01-03 15:11 GMT+01:00 Henning Thielemann :

...

On Tue, 3 Jan 2017, Edward Kmett wrote:

...
From the discussion so far, feedback seems overwhelmingly positive on making the change, so everything I say here just assumes we're going forward.

I do not understand the feedback this way. There were strong arguments against adding and I thought that we do not simply count votes.

I have to agree that the feedback on this mailing list was IMHO a bit less than "overwhelmingly positive" so far. There was some feedback on the r/haskell thread [1] where I had linked my proposal, and that was IMO quite enthusiastic. [1] https://www.reddit.com/r/haskell/comments/5kobcf/proposal_add_readmaybe_and_...

Phil Ruffwind

5 Jan 5 Jan

9:01 a.m.

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

Kris Nuttycombe

11:22 a.m.

On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind wrote:

...

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

This strikes me as the right avenue to pursue. While I'd personally be happy to expunge partial functions from base entirely, I recognize that others have different needs - and a {-# PARTIAL #-} pragma would have broad utility. Coupled with a -fno-warn-partial flag, users would be able to opt-in to the status quo, but the default would be to steer people away from partial functions, which seems like the right thing. For new users, the warnings would be educational, since for many people coming from languages where many "functions" are partial the idea of totality is something that needs to be learned. Kris

Mario Blažević

11:50 a.m.

On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:

...

On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind mailto:rf@rufflewind.com> wrote:

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

This strikes me as the right avenue to pursue. While I'd personally be happy to expunge partial functions from base entirely, I recognize that others have different needs - and a {-# PARTIAL #-} pragma would have broad utility. Coupled with a -fno-warn-partial flag, users would be able to opt-in to the status quo, but the default would be to steer people away from partial functions, which seems like the right thing. For new users, the warnings would be educational, since for many people coming from languages where many "functions" are partial the idea of totality is something that needs to be learned.

I like this idea the best so far. Two more points: - haddock should generate some warning in documentation from the {-# PARTIAL #-} pragma, so there should probably be an optional warning message, as in {-# PARTIAL "`head` expects a non-empty list" #-} - -fno-warn-partial should be called -Wno-partial to fit the other warning flags Also, GHC already generates partiality warnings with -Wincomplete-patterns, they're just not on by default. Would these be affected? Should haddock generate warnings for incomplete patterns in documentation, and is there any relation between -Wno-partial and -Wno-incomplete-patterns?

David Feuer

12:01 p.m.

One tricky point is that there are partial functions we usually prefer to pretend are total. For example, Data.Map.insert is partial: if size m = maxBound :: Int, then the result of insert k v m is nonsense (this may be possible in a 32-bit system with lots of memory). A similar restriction holds in Data.Sequence, but could even be hit in a 64-bit system with virtually no memory using, e.g., () <| replicate maxBound (). So there are shades of partiality we want to worry about and partiality we don't, depending on what we're doing. On Jan 5, 2017 11:50 AM, "Mario Blažević" wrote:

...

On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:

...
On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind > wrote:

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

This strikes me as the right avenue to pursue. While I'd personally be happy to expunge partial functions from base entirely, I recognize that others have different needs - and a {-# PARTIAL #-} pragma would have broad utility. Coupled with a -fno-warn-partial flag, users would be able to opt-in to the status quo, but the default would be to steer people away from partial functions, which seems like the right thing. For new users, the warnings would be educational, since for many people coming from languages where many "functions" are partial the idea of totality is something that needs to be learned.

I like this idea the best so far. Two more points:

- haddock should generate some warning in documentation from the {-# PARTIAL #-} pragma, so there should probably be an optional warning message, as in {-# PARTIAL "`head` expects a non-empty list" #-} - -fno-warn-partial should be called -Wno-partial to fit the other warning flags

Also, GHC already generates partiality warnings with -Wincomplete-patterns, they're just not on by default. Would these be affected? Should haddock generate warnings for incomplete patterns in documentation, and is there any relation between -Wno-partial and -Wno-incomplete-patterns?

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

David Feuer

12:06 p.m.

Perhaps an even better example is integer division. It's most assuredly partial, but I don't think anyone wants to get a warning every time they use it. On Jan 5, 2017 12:01 PM, "David Feuer" wrote:

...

One tricky point is that there are partial functions we usually prefer to pretend are total. For example, Data.Map.insert is partial: if size m = maxBound :: Int, then the result of insert k v m is nonsense (this may be possible in a 32-bit system with lots of memory). A similar restriction holds in Data.Sequence, but could even be hit in a 64-bit system with virtually no memory using, e.g., () <| replicate maxBound (). So there are shades of partiality we want to worry about and partiality we don't, depending on what we're doing.

On Jan 5, 2017 11:50 AM, "Mario Blažević" wrote:

...
On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:

...
On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind mailto:rf@rufflewind.com> wrote:

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

This strikes me as the right avenue to pursue. While I'd personally be happy to expunge partial functions from base entirely, I recognize that others have different needs - and a {-# PARTIAL #-} pragma would have broad utility. Coupled with a -fno-warn-partial flag, users would be able to opt-in to the status quo, but the default would be to steer people away from partial functions, which seems like the right thing. For new users, the warnings would be educational, since for many people coming from languages where many "functions" are partial the idea of totality is something that needs to be learned.

I like this idea the best so far. Two more points:

- haddock should generate some warning in documentation from the {-# PARTIAL #-} pragma, so there should probably be an optional warning message, as in {-# PARTIAL "`head` expects a non-empty list" #-} - -fno-warn-partial should be called -Wno-partial to fit the other warning flags

Also, GHC already generates partiality warnings with -Wincomplete-patterns, they're just not on by default. Would these be affected? Should haddock generate warnings for incomplete patterns in documentation, and is there any relation between -Wno-partial and -Wno-incomplete-patterns?

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

Edward Kmett

4:33 p.m.

There is a rather broad continuum of notions of partiality you might want to capture in such an annotation. Possible non-termination is a form of partiality after all.

...

length (cycle [1])

We don't have (or even necessarily want) a sufficiently nuanced fancy dependent type system that all such notions of partiality can (or should) be stomped out. -Edward On Thu, Jan 5, 2017 at 12:06 PM, David Feuer wrote:

...

Perhaps an even better example is integer division. It's most assuredly partial, but I don't think anyone wants to get a warning every time they use it.

On Jan 5, 2017 12:01 PM, "David Feuer" wrote:

...
One tricky point is that there are partial functions we usually prefer to pretend are total. For example, Data.Map.insert is partial: if size m = maxBound :: Int, then the result of insert k v m is nonsense (this may be possible in a 32-bit system with lots of memory). A similar restriction holds in Data.Sequence, but could even be hit in a 64-bit system with virtually no memory using, e.g., () <| replicate maxBound (). So there are shades of partiality we want to worry about and partiality we don't, depending on what we're doing.

On Jan 5, 2017 11:50 AM, "Mario Blažević" wrote:

...
On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:

...
On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind mailto:rf@rufflewind.com> wrote:

Rather than deprecating a function, it would be nice to have some sort of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial function (and similarly for 'head', 'tail' and its friends), much like how GHC already warns about partial case-blocks. That being said, it's probably best to delay this until there is a way to explicitly turn of the warnings individually at the call site for those who want warning-free code.

This strikes me as the right avenue to pursue. While I'd personally be happy to expunge partial functions from base entirely, I recognize that others have different needs - and a {-# PARTIAL #-} pragma would have broad utility. Coupled with a -fno-warn-partial flag, users would be able to opt-in to the status quo, but the default would be to steer people away from partial functions, which seems like the right thing. For new users, the warnings would be educational, since for many people coming from languages where many "functions" are partial the idea of totality is something that needs to be learned.

I like this idea the best so far. Two more points:

- haddock should generate some warning in documentation from the {-# PARTIAL #-} pragma, so there should probably be an optional warning message, as in {-# PARTIAL "`head` expects a non-empty list" #-} - -fno-warn-partial should be called -Wno-partial to fit the other warning flags

Also, GHC already generates partiality warnings with -Wincomplete-patterns, they're just not on by default. Would these be affected? Should haddock generate warnings for incomplete patterns in documentation, and is there any relation between -Wno-partial and -Wno-incomplete-patterns?

_______________________________________________ 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

Edward Kmett

3 Jan 3 Jan

7:53 a.m.

On Mon, Jan 2, 2017 at 10:10 AM, Simon Jakobi wrote:

...

There are quite a few packages [1] that define their private version of readMaybe, but I don't think that these should be counted as arguments _against_ adding the function to Prelude.

Also, those in that list that happen to import it from Text.Read rather than define it themselves would still work just fine. -Edward

...

Simon

[1] https://github.com/search?l=Haskell&q=readMaybe&type=Code

Simon Jakobi

28 Dec 28 Dec

8:39 p.m.

2016-12-28 17:12 GMT+01:00 Henning Thielemann :

...

I would be ok with deprecating 'read'.

That seems like a reasonable idea but I would prefer to discuss it in a separate thread.

3006

Age (days ago)

3065

Last active (days ago)

List overview

Download

49 comments

23 participants

participants (23)

amindfv＠gmail.com
Andreas Abel
Andrew Butterfield
Andrew Martin
Artyom
Bardur Arantsson
Ben Franksen
David Feuer
David Menendez
Edward Kmett
Henning Thielemann
Henrik Nilsson
Ivan Lazar Miljenovic
Kris Nuttycombe
Mario Blažević
Mario Blažević
Phil Ruffwind
Simon Jakobi
Sven Panne
Theodore Lief Gannon
Tom Murphy
Yitzchak Gale
Yuras Shumovich