I'm strongly in favor of removing this so as not to confuse new people with partial functions that have impossible type signatures. +1 On 02/23/2015 11:49 PM, Ivan Lazar Miljenovic wrote:

On 24 February 2015 at 16:42, Erik de Castro Lopo wrote:

...

Hi all,

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

Comments? I've used fromJust in the past when I knew the value would be Just by construction.

That said, I could always have written my own fromJust function with a custom error message, and did switch some of them to direct pattern matches (so that at least the error message said *where* the error occurred).

So I'm undecided; maybe (no pun intended!) -0.1.

...

Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Andrew Gibiansky writes:

I am strongly against this, as sometimes you *do* want to use fromJust. For example:

What people want isn’t necessarily good language design.

1. Quick and dirty scripting/examples where you don't care about error-proofing your work and just want it to be done quickly. In that context, fromJust is a good function.

but you can have your own library that contains “fromMaybe undefined” as well as all the other quick and dirty functions useful for one-off programmes.

2. You know by construction that it is a Just constructor. This is usually not a good design, but sometimes it's useful. Writing an (error "fromJust") is possible, but annoying.

Programming languages accrue all sorts of bad practices from that sort of argument. Good Haskell programming involves making the type system move as many errors as possible from run time to compile time.

(That said, I do wish that `head` and `tail` were replaced by `headMay` and `tailMay`, which you could then use with `fromJust` if you wanted to. But that's another discussion for adding things from `safe` to `base`, unrelated...)

I’m with you on that. So I’m +1 on the proposal. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

On 24 February 2015 at 21:06, Oliver Charles wrote:

Everyone is talking about wanting a function to do this, but I'd argue an inline case statement is better. Whenever you have

f (fromJust x)

You can write

f (case x of Just x' -> x')

Which is even more fugly if you have more function composition after the usage of fromJust (though I suppose LambdaCase makes it a tad nicer).

Its a little more typing, but the big wins are:

- a warning that you're relying on partiality - a useful error message if your assumption fails, giving you the line number of the pattern match failure.

These are both superior to fromJust, so I can see no reason for it to exist. If its useful in GHCI then add it to your .ghci. If you think everyone should have it by default, then maybe we should have a conversation about a "GHCI prelude".

+1, death to hidden partiality!

ocharles

On 24 Feb 2015 09:36, "Jon Fairbairn" wrote:

...

Andrew Gibiansky writes:

...

I am strongly against this, as sometimes you *do* want to use fromJust. For example:

What people want isn’t necessarily good language design.

...

1. Quick and dirty scripting/examples where you don't care about error-proofing your work and just want it to be done quickly. In that context, fromJust is a good function.

but you can have your own library that contains “fromMaybe undefined” as well as all the other quick and dirty functions useful for one-off programmes.

...

2. You know by construction that it is a Just constructor. This is usually not a good design, but sometimes it's useful. Writing an (error "fromJust") is possible, but annoying.

Programming languages accrue all sorts of bad practices from that sort of argument. Good Haskell programming involves making the type system move as many errors as possible from run time to compile time.

...

(That said, I do wish that `head` and `tail` were replaced by `headMay` and `tailMay`, which you could then use with `fromJust` if you wanted to. But that's another discussion for adding things from `safe` to `base`, unrelated...)

I’m with you on that.

So I’m +1 on the proposal.

-- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk

_______________________________________________ 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

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

Ivan Lazar Miljenovic wrote:

I've used fromJust in the past when I knew the value would be Just by construction.

I have too. And then a less experienced haskell dev saw that usage in code that I had written and used it elsewhere without the same assurances. I didn't notice and the Yesod webapp was deployed to production and two days later we had a report of "Exception: Maybe.fromJust: Nothing" showing up in web pages. Embarassing to say the least. We removed all usage of fromJust. However, if *i* had used fromMaybe to begin with its *highly* likely that my colleague would have followed my lead and highly likely he would have *thought* about the Nothing case.

That said, I could always have written my own fromJust function with a custom error message, and did switch some of them to direct pattern matches (so that at least the error message said *where* the error occurred).

Exactly. This: fromMaybe (error "Module.functionName : unexpected Nothing") x is hugely preferable to fromJust. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Tue, 24 Feb 2015, Ivan Lazar Miljenovic wrote:

I've used fromJust in the past when I knew the value would be Just by construction.

If you know that the value is always Just by construction, why don't you express this with the types, i.e. by turning from 'Maybe a' to 'a'? When asking this question myself I could remove fromJusts in most cases. The problem is most oftenly that you drop the information that a value is Just too early and then you cannot recover it later.

On Tue, 24 Feb 2015, Joachim Breitner wrote:

Hi,

Am Dienstag, den 24.02.2015, 11:14 +0100 schrieb Henning Thielemann:

...

On Tue, 24 Feb 2015, Ivan Lazar Miljenovic wrote:

...

I've used fromJust in the past when I knew the value would be Just by construction.

If you know that the value is always Just by construction, why don't you express this with the types, i.e. by turning from 'Maybe a' to 'a'?

Not everything can be expressed with types.

Example: You build a graph data structure around Data.Map. Your abstract interface makes sure that in your graph, you only reference nodes that are in the domain of the map. So it is reasonable to use "fromJust (M.lookup key map)"¹ internally.

Yes, there are these cases where the prover capabilities of current Haskell are too weak. We should use "fromMaybe (error msg)" in this case. The error message could also give inspectors of the code an idea why the programmer thinks that the error never occurs. However, I bet that half of the uses of fromJust on Hackage can be replaced by something total.

-1 for this reason. A strong recommendation in the docs is enough. There are legitimate uses and the busy work involved in fixing the 10,000 uses is not with it. That's time that could be spent on more libraries. On Feb 24, 2015 7:19 AM, "Chris Allen" wrote:

Just a quick look on Github, filtering for uses of fromJust rather than re-declarations (mostly), shows 9,418 uses.

https://github.com/search?utf8=%E2%9C%93&q=extension% 3Ahs+fromJust+%22import+Data.Maybe%22&type=Code&ref=searchresults

Searching for imports of Data.Maybe alone come to 19,985, indicating that at least ~half of the time people import Data.Maybe, they're using fromJust.

https://github.com/search?utf8=%E2%9C%93&q=extension% 3Ahs+%22import+Data.Maybe%22&type=Code&ref=searchresults

As a baseline, Data.List shows up 28k times.

https://github.com/search?utf8=%E2%9C%93&q=extension% 3Ahs+%22import+Data.List%22&type=Code&ref=searchresults

This is just from a 3 minute glance. If we really want to narrow it down to Hackage I'll do something more thorough.

On 02/24/2015 12:13 AM, Bardur Arantsson wrote:

...

On 24-02-2015 06:42, Erik de Castro Lopo wrote:

...

Hi all,

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

Comments?

How much code on Hackage is currently using fromJust? (A rough estimate by group would probably be sufficient.)

Regards,

_______________________________________________ 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

On Mon, Feb 23, 2015 at 10:19 PM, Chris Allen wrote:

Just a quick look on Github, filtering for uses of fromJust rather than re-declarations (mostly), shows 9,418 uses. ... Searching for imports of Data.Maybe alone come to 19,985, indicating that at least ~half of the time people import Data.Maybe, they're using fromJust.

Are you guys crazy?! I don't like partial functions either, but forget the -1, I vote to nuke this thread from orbit. I'm +1 to adding warning pragmas to the prelude's partial functions, however. G -- Gregory Collins

On Tue, 24 Feb 2015, Greg Weber wrote:

Michael and I came up with an approach of using a convention in mono-traversable where any partial function has the postfix `Ex`, which stands for (throws a pure) Exception. So there is a `headEx` and `tailEx` function. This is a very light-weight solution although it is certainly easy for someone to ignore a new naming convention.

The only problem is, that "error" is not an exception, but, well, an error. Why not naming partial functions with something that reminds on "partial"?

On 24/02/15 11:28, Erik de Castro Lopo wrote:

Roman Cheplyaka wrote:

...

Say I have

parse :: String -> Maybe Value process :: Value -> IO ()

Then (process . fromJust . parse) is the fastest way to compose the two.

Wouldn't

process fromMaybe defaultValue . parse

do as well?

It sure would, just more typing (and a bit more thinking). Roman

Joachim Breitner wrote:

-1

If it wasn’t there, I probably would not vote for adding it, but in the interest of general stability, I believe removing this function is not worth the effort.

I think its interesting (I've heard this from a couple of people) that if this function was up for *addition* it would be rejected, but they do not support its removal or even deprecation.

Also, just removing fromMaybe when there are many other partial

Not fromMaybe (which is total), fromJust (which is partial) :-).

functions, some in the Prelude, does not really cut it. If there was a larger proposal „Make Haskell free of Partial Functions“, then that would be a different thing.

Maybe this is a like strictness; Haskell users don't want a strict version of Haskell so much as a Haskell where they have better control over the the tradeoffs between lazy and strict evaluation. Possibly what we need is a pragma to mark functions partial and a warning flag that warns on usage of functions that have been marked partial. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

And I did it myself, as it was about adding one single line rule: https://github.com/ndmitchell/hlint/pull/115 https://github.com/ndmitchell/hlint/pull/115 Let’s see what Neil thinks about :) - Oleg

On 24 Feb 2015, at 12:28, Oleg Grenrus wrote:

...

On 24 Feb 2015, at 12:23, Erik de Castro Lopo mailto:mle+hs@mega-nerd.com> wrote:

Possibly what we need is a pragma to mark functions partial and a warning flag that warns on usage of functions that have been marked partial.

I had this in mind too, but that is very heavy solution. I’d rather start with making hlint warnings?

foo :: Maybe Int -> Int foo x = if isJust x then fromJust x else 0

bar :: Maybe Int -> Int bar x = 1 + fromJust x

It warns about `foo` nonsense. It could propose to change `bar` part into `fromMaybe (error “I’know what I’m doing”) x` ?

- Oleg

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

Hi, Am Dienstag, den 24.02.2015, 02:23 -0800 schrieb Erik de Castro Lopo:

...

-1

If it wasn’t there, I probably would not vote for adding it, but in the interest of general stability, I believe removing this function is not worth the effort.

I think its interesting (I've heard this from a couple of people) that if this function was up for *addition* it would be rejected, but they do not support its removal or even deprecation.

Every change has its cost, addition and removal, and stability is a useful goal of its own. So if the benefits are not convincing, the change should not happen. Clearly if we would design the Haskell libraries from the ground up, we would do a _lot_ of things differently, wouldn’t we? I think deprecation should be used for things that are going to be removed, hence I’m not in favor or deprecating it either.

Possibly what we need is a pragma to mark functions partial and a warning flag that warns on usage of functions that have been marked partial.

Right, see my other mail where I propose the same thing :-) I find hat a very good way forward and would be willing to guide anyone who wants to implement that in GHC. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

On 2015-02-24 at 11:30:33 +0100, Joachim Breitner wrote: [...]

...

Possibly what we need is a pragma to mark functions partial and a warning flag that warns on usage of functions that have been marked partial.

Right, see my other mail where I propose the same thing :-) I find hat a very good way forward and would be willing to guide anyone who wants to implement that in GHC.

Seems a few of us want this (saw those emails only after I already sent my mail redundantly proposing a very similiar feature[1])... let's try to implement this feature for 7.12 ... I already know SPJ will ask for a GHC Wiki page describing the proposed design :-) [1] https://mail.haskell.org/pipermail/libraries/2015-February/025044.html

Hi, Am Dienstag, den 24.02.2015, 11:11 +0100 schrieb Henning Thielemann:

On Mon, 23 Feb 2015, Erik de Castro Lopo wrote:

...

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I would deprecate it, but not remove it. Otherwise people will think that this obvious function is missing by accident. We would then encounter various discussions about adding it in the close future.

that’s a more useful idea, but again: Why fromJust and not head etc.? If you would continue this thought of line towards some consistency, then we’d need a way to annotate partial functions in general, and have a dedicated flag -fwarn-partial-functions. (It would behave just like deprecations – but reported separately.). This would go well with -fwarn-incomplete-patterns. Such a thing might be useful. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Hi, Am Dienstag, den 24.02.2015, 11:33 +0100 schrieb Henning Thielemann:

On Tue, 24 Feb 2015, Joachim Breitner wrote:

...

If you would continue this thought of line towards some consistency, then we’d need a way to annotate partial functions in general, and have a dedicated flag -fwarn-partial-functions. (It would behave just like deprecations – but reported separately.). This would go well with -fwarn-incomplete-patterns. Such a thing might be useful.

I have thought about it in the past and it is certainly better than no such warning. On the other hand partiality can be caused by infinite loops and is then hard to detect. To be completely sure you would have to implement a termination checker as in liquid-haskell. Nonetheless, a partiality marker for every function that might call 'error' or 'undefined' would be useful.

note that I am not proposing that GHC would figure out what is total and what not, but simply that you could say fromJust :: Maybe a -> a fromJust (Just a) = a {-# WARNING (partial) fromJust "fromJust is partial #-} and the user will see the warnings if he enables -fwarn-partial. If no such annotation is given, no warning is printed. A proper totally checker would be a whole different beast :-) (Note that here, I am inventing a syntax to categorize the warnings into groups, so that the user can choose whether to see partiality warnings or not independently from other uses of WARNING.) Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

On Tue, 24 Feb 2015, Michael Snoyman wrote:

We could also automatically detect basic partiality, like incomplete pattern matches, and add partiality warnings. Depending on how much work that is, it may be easier than trying to mark up all of base correctly.

I think that, too

I've been wanting to get warnings on partial functions (and partial record accessors, while we're at it!) for some time. And, I think it would be quite easy to have GHC infer partiality. As far as I can see, partiality can come from only two places: the use of a partial function, and an incomplete pattern match. (I'm ignoring nontermination here, which I think is best considered separately.) Before getting this into GHC, though, we'd need to make sure the incomplete-pattern-match checker is up for it (see #3927), but that work is being done right now. And we'd definitely need a way for users to declare "This function is total! Really!" I like the idea of user-specified warning categories, but I think partiality is easy enough for GHC to infer that it should be built in. +1 on partiality warnings, preferably inferred +0.8 on user-specified warning classes (but inferred partiality is my preference) -0.9 on just attaching a one-off warning to fromJust (we can do so much better) -1 on removing fromJust (I use it myself [don't hate me for it], and the GHC codebase uses `expectJust`, which takes a string for better error messages, 54 times by my count) Richard On Feb 24, 2015, at 7:28 AM, Herbert Valerio Riedel wrote:

On 2015-02-24 at 12:32:14 +0100, Michael Snoyman wrote:

...

We could also automatically detect basic partiality, like incomplete pattern matches, and add partiality warnings. Depending on how much work that is, it may be easier than trying to mark up all of base correctly.

You'd still need a way to greenlight false positives. I.e. cases where the code *seems* to have unhandled pattern matches which can't happen, but which GHC can't prove them not to be unhandled... _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

We are working on detecting partiality in pattern matching right now S | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Richard Eisenberg | Sent: 24 February 2015 15:02 | To: Herbert Valerio Riedel | Cc: libraries@haskell.org; Joachim Breitner | Subject: Re: Proposal to deprecate and then drop fromJust | | I've been wanting to get warnings on partial functions (and partial | record accessors, while we're at it!) for some time. | | And, I think it would be quite easy to have GHC infer partiality. As | far as I can see, partiality can come from only two places: the use of | a partial function, and an incomplete pattern match. (I'm ignoring | nontermination here, which I think is best considered separately.) | Before getting this into GHC, though, we'd need to make sure the | incomplete-pattern-match checker is up for it (see #3927), but that | work is being done right now. And we'd definitely need a way for users | to declare "This function is total! Really!" | | I like the idea of user-specified warning categories, but I think | partiality is easy enough for GHC to infer that it should be built in. | | +1 on partiality warnings, preferably inferred | +0.8 on user-specified warning classes (but inferred partiality is my | +preference) | | -0.9 on just attaching a one-off warning to fromJust (we can do so | much better) | -1 on removing fromJust (I use it myself [don't hate me for it], and | the GHC codebase uses `expectJust`, which takes a string for better | error messages, 54 times by my count) | | Richard | | On Feb 24, 2015, at 7:28 AM, Herbert Valerio Riedel | wrote: | | > On 2015-02-24 at 12:32:14 +0100, Michael Snoyman wrote: | >> We could also automatically detect basic partiality, like | incomplete | >> pattern matches, and add partiality warnings. Depending on how much | >> work that is, it may be easier than trying to mark up all of base | >> correctly. | > | > You'd still need a way to greenlight false positives. I.e. cases | where | > the code *seems* to have unhandled pattern matches which can't | happen, | > but which GHC can't prove them not to be unhandled... | > _______________________________________________ | > 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

On 24-02-2015 11:15, Joachim Breitner wrote:

Hi,

Am Dienstag, den 24.02.2015, 11:11 +0100 schrieb Henning Thielemann:

...

On Mon, 23 Feb 2015, Erik de Castro Lopo wrote:

...

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I would deprecate it, but not remove it. Otherwise people will think that this obvious function is missing by accident. We would then encounter various discussions about adding it in the close future.

-1 to the original proposal. Obviously -- it would cause far too much breakage for very little upside.

that’s a more useful idea, but again: Why fromJust and not head etc..?

If you would continue this thought of line towards some consistency, then we’d need a way to annotate partial functions in general, and have a dedicated flag -fwarn-partial-functions. (It would behave just like deprecations – but reported separately.). This would go well with -fwarn-incomplete-patterns. Such a thing might be useful.

Yes, this would definitely be useful. (Should perhaps be turned on by default for non-ghci? That might usefull help prod unaware people in the direction of total functions.) Then in 2020 or 2025 or so someone could do a survey of github/hackage to see what the breakage would be from actually froming fromJust, &c. Regards,

On Tue Feb 24 2015 at 12:47:07 PM Herbert Valerio Riedel wrote:

On 2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:

...

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I'm +1 for deprecating (or attach a warning pragma to) 'fromJust' as I've been bit by 'fromJust' myself in the past, when I was still mixing up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out for 'fromJust' anymore at all.

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Relatedly, I was thinking of a separate 'partial-functions' warning class, so we could annotate partial functions (head/last/...) in base, and have the associated warnings be tunable via a separate GHC -fwarn* flag. This could even be generalised to arbitrary warning-classes:

{-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}

I'm sure we would come up with other useful warning-classes...

This sounds like a great idea, which I'd support fully. The idea of letting people opt-out of partiality warnings somehow would IMO address the concerns here perfectly. Even though I'm strongly opposed to fromJust, I'm -1 on removing it any time soon due to ensuing breakage. I'm on the fence with a standard deprecation warning (since by what I just said we really *aren't* deprecating it), but a WARNING would be great. Michael

I think this is a great case for the proposed deprecated export feature. Instead of deprecating fromJust, we move it to Data.Maybe.Partial and deprecate its export from Prelude and Data.Maybe. On Feb 24, 2015 2:07 PM, "Chris Allen" wrote:

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Terrifyingly, yes. I fired off a shell-script to cabal unpack all the libraries on Hackage last night and some cursory grepping has brought me:

1,176 instances of where fromJust is explicitly imported from Data.Maybe 7,431 instances of fromJust mentioned in a Haskell source file

I'm in favour (+1) of the deprecation (warnings) cycle proposal kicked around.

Also if anyone knows of a semantically aware (ie, can distinguish functions, imports, etc.) open source code search tool, I'd be very grateful if they'd point me in that direction.

On 02/24/2015 04:54 AM, Michael Snoyman wrote:

On Tue Feb 24 2015 at 12:47:07 PM Herbert Valerio Riedel wrote:

...

On 2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:

...

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I'm +1 for deprecating (or attach a warning pragma to) 'fromJust' as I've been bit by 'fromJust' myself in the past, when I was still mixing up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out for 'fromJust' anymore at all.

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Relatedly, I was thinking of a separate 'partial-functions' warning class, so we could annotate partial functions (head/last/...) in base, and have the associated warnings be tunable via a separate GHC -fwarn* flag. This could even be generalised to arbitrary warning-classes:

{-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}

I'm sure we would come up with other useful warning-classes...

This sounds like a great idea, which I'd support fully. The idea of letting people opt-out of partiality warnings somehow would IMO address the concerns here perfectly.

Even though I'm strongly opposed to fromJust, I'm -1 on removing it any time soon due to ensuing breakage. I'm on the fence with a standard deprecation warning (since by what I just said we really *aren't* deprecating it), but a WARNING would be great.

Michael

_______________________________________________ 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

-1 I'm personally pretty strongly against removing this function on mere proscriptive grounds and a deprecation is effectively removal for most users who care about warnings. I wouldn't have voted to add it in the first place, but now that it is here and in wide use asking several thousand occurrences on hackage to change to suit your sensibilities and use more verbose alternatives seems to be rather brutal. That said, I'd fully support putting in strong wording in the documentation about the partial nature of the function. -Edward On Tue, Feb 24, 2015 at 2:07 PM, Chris Allen wrote:

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Terrifyingly, yes. I fired off a shell-script to cabal unpack all the libraries on Hackage last night and some cursory grepping has brought me:

1,176 instances of where fromJust is explicitly imported from Data.Maybe 7,431 instances of fromJust mentioned in a Haskell source file

I'm in favour (+1) of the deprecation (warnings) cycle proposal kicked around.

Also if anyone knows of a semantically aware (ie, can distinguish functions, imports, etc.) open source code search tool, I'd be very grateful if they'd point me in that direction.

On 02/24/2015 04:54 AM, Michael Snoyman wrote:

On Tue Feb 24 2015 at 12:47:07 PM Herbert Valerio Riedel wrote:

...

On 2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:

...

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I'm +1 for deprecating (or attach a warning pragma to) 'fromJust' as I've been bit by 'fromJust' myself in the past, when I was still mixing up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out for 'fromJust' anymore at all.

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Relatedly, I was thinking of a separate 'partial-functions' warning class, so we could annotate partial functions (head/last/...) in base, and have the associated warnings be tunable via a separate GHC -fwarn* flag. This could even be generalised to arbitrary warning-classes:

{-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}

I'm sure we would come up with other useful warning-classes...

This sounds like a great idea, which I'd support fully. The idea of letting people opt-out of partiality warnings somehow would IMO address the concerns here perfectly.

Even though I'm strongly opposed to fromJust, I'm -1 on removing it any time soon due to ensuing breakage. I'm on the fence with a standard deprecation warning (since by what I just said we really *aren't* deprecating it), but a WARNING would be great.

Michael

_______________________________________________ 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

I don't think the PARTIAL pragma should be necessary. The imprecise exception-throwing primitive(s) should be considered partial automatically, and everything flows from there. I think the TOTAL pragma should mean "Error out if you can't prove totality", while CONSIDER_TOTAL should override the inference. On Feb 24, 2015 2:52 PM, "Edward Kmett" wrote:

FWIW- I would very much support a notion of a "partiality inference" as long as we had something like a {-# PARTIAL #-} pragma for when something like a useful error message is masking an otherwise actual partial function and a {-# TOTAL #-} pragma for where GADT inference is just failing to realize some cases are impossible.

If folks wanted to go down that road, a lot of user code could benefit from this sort of system, and I could see a nice separate class of warnings for the issue.

It'd be a damn sight more work, but I think it'd be worth it.

This would let folks opt in or out, depending on which way we went to this extra social contract.

-Edward

On Tue, Feb 24, 2015 at 2:32 PM, Edward Kmett wrote:

...

-1

I'm personally pretty strongly against removing this function on mere proscriptive grounds and a deprecation is effectively removal for most users who care about warnings.

I wouldn't have voted to add it in the first place, but now that it is here and in wide use asking several thousand occurrences on hackage to change to suit your sensibilities and use more verbose alternatives seems to be rather brutal.

That said, I'd fully support putting in strong wording in the documentation about the partial nature of the function.

-Edward

On Tue, Feb 24, 2015 at 2:07 PM, Chris Allen wrote:

...

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Terrifyingly, yes. I fired off a shell-script to cabal unpack all the libraries on Hackage last night and some cursory grepping has brought me:

1,176 instances of where fromJust is explicitly imported from Data.Maybe 7,431 instances of fromJust mentioned in a Haskell source file

I'm in favour (+1) of the deprecation (warnings) cycle proposal kicked around.

Also if anyone knows of a semantically aware (ie, can distinguish functions, imports, etc.) open source code search tool, I'd be very grateful if they'd point me in that direction.

On 02/24/2015 04:54 AM, Michael Snoyman wrote:

On Tue Feb 24 2015 at 12:47:07 PM Herbert Valerio Riedel wrote:

...

On 2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:

...

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

I'm +1 for deprecating (or attach a warning pragma to) 'fromJust' as I've been bit by 'fromJust' myself in the past, when I was still mixing up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out for 'fromJust' anymore at all.

However, I think it'll require a very long deprecation cycle before actually removing it from base, as 'fromJust' is officially part of Haskell 2010, and there's probably a lot of code out there using 'fromJust'...

Relatedly, I was thinking of a separate 'partial-functions' warning class, so we could annotate partial functions (head/last/...) in base, and have the associated warnings be tunable via a separate GHC -fwarn* flag. This could even be generalised to arbitrary warning-classes:

{-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}

I'm sure we would come up with other useful warning-classes...

This sounds like a great idea, which I'd support fully. The idea of letting people opt-out of partiality warnings somehow would IMO address the concerns here perfectly.

Even though I'm strongly opposed to fromJust, I'm -1 on removing it any time soon due to ensuing breakage. I'm on the fence with a standard deprecation warning (since by what I just said we really *aren't* deprecating it), but a WARNING would be great.

Michael

_______________________________________________ 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

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

On Tue, Feb 24, 2015 at 6:35 PM, Ben Millwood wrote:

But surely the *entire purpose* of deprecations is to be *less* damaging than removals, and so if we're implicitly considering them equally bad, that suggests to me that our deprecation mechanism is totally broken, and needs to be fixed.

If deprecation is not considered to be "removal upcoming, fix your code now" then there is no point to deprecation. I don't understand your point otherwise. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

One option is to recognize two kinds of deprecation 1. Traditional GHC style: deprecated = we will remove this soon 2. Traditional some-other-places style: deprecated = we advise against using this On Tue, Feb 24, 2015 at 6:55 PM, Greg Weber wrote:

Even if warnings are treated as errors, it is not correct because you can turn off deprecation warnings. To be fine-grained you can create a single module where deprecated things are imported and then re-exported, but that module has deprecation warnings turned off. Certainly that is extra work, but it is easier than most would imagine.

On Tue, Feb 24, 2015 at 3:35 PM, Ben Millwood wrote:

...

I'm going to grab this quotation from a recent thread discussing removal of fromJust:

On Tue, Feb 24, 2015 at 02:32:08PM -0500, Edward Kmett wrote:

...

I'm personally pretty strongly against removing this function on mere proscriptive grounds and a deprecation is effectively removal for most users who care about warnings.

This strikes me as troubling. Are we considering deprecations to be equivalent to removals, in terms of stability impact? I've heard more than one person suggest that we are, or should. The argument for it is reasonably clear: with -Werror enabled, as many people do, as many would encourage, even, either removal or deprecation of something you use will break your build.

But surely the *entire purpose* of deprecations is to be *less* damaging than removals, and so if we're implicitly considering them equally bad, that suggests to me that our deprecation mechanism is totally broken, and needs to be fixed.

I can think of several potential fixes, but I'd first like to see if others agree that there is a problem :) _______________________________________________ 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

A deprecation definitely signals an intent to *eventually* remove. My point was more that around that particular combinator there are a lot of arguably legitimate users by users who aren't going to be inclined to remove it, because it does capture their intent. For all that a subset of the community is very vocally against the use of partial functions like head, tail, fromJust, (!!), etc. deprecation should send a clear signal and it doesn't strike me that the disquiet over those combinators had risen to the level of overwhelming consent it would take to start marking this whole style of programming as deprecated. Now, if we want to go after supplying a warning class for partial functions and let people opt in or out of it, that seems like another matter entirely. It doesn't require us to put these things on a clock for removal and folks can continue to agree to disagree about the relative merits of this style. It would also let us go much farther and enable separately configurable warnings across a much wider array of functions than just fromJust. -Edward On Tue, Feb 24, 2015 at 6:35 PM, Ben Millwood wrote:

I'm going to grab this quotation from a recent thread discussing removal of fromJust:

On Tue, Feb 24, 2015 at 02:32:08PM -0500, Edward Kmett wrote:

...

I'm personally pretty strongly against removing this function on mere proscriptive grounds and a deprecation is effectively removal for most users who care about warnings.

This strikes me as troubling. Are we considering deprecations to be equivalent to removals, in terms of stability impact? I've heard more than one person suggest that we are, or should. The argument for it is reasonably clear: with -Werror enabled, as many people do, as many would encourage, even, either removal or deprecation of something you use will break your build.

But surely the *entire purpose* of deprecations is to be *less* damaging than removals, and so if we're implicitly considering them equally bad, that suggests to me that our deprecation mechanism is totally broken, and needs to be fixed.

I can think of several potential fixes, but I'd first like to see if others agree that there is a problem :)

+1 to {-# WARNING #-} +0.5 to deprecation/removal I've used it, but for all the fans of fromJust, here's some code golf: (fromMaybe (error "impossible")) (fromMaybe undefined) (\(Just x) -> x) The last one is shortest, and with it ghc can tell you you're doing something partial. Tom On Wed, Feb 25, 2015 at 1:25 AM, Konstantine Rybnikov wrote:

Maybe it would make sense to incorporate fromJustNote (as in `safe` package) and highly recommend that one in docs? It makes it easier to debug error and to realize that it will throw an error on Nothing. 25 лют. 2015 00:36, користувач "Daniel Díaz" написав:

Hi.

...

This function has been guilty (more than once) of making my debugging harder by providing too little error information. Sure, the programmer who wrote the code should have made sure that the argument could not possibly be Nothing, but that didn't stopped him/her to use fromJust. Yes, there is always a way to make an "error" happen, but without fromJust you'll have to do so explicitly. I think we should encourage good practices. Just my point of view.

The downside I see are the current occurrences of fromJust all around. I guess they are a huge lot. Although I would love to get rid of them, this would require some work (even if it's very little) from a lot of developers. So if we want to do this, a consensus must be built first.

Therefore, +1 from me.

Best regards, Daniel Díaz.

On 02/24/2015 06:42 AM, Erik de Castro Lopo wrote:

...

Hi all,

We currently have in the Data.Maybe module from base:

fromJust :: Maybe a -> a

which newbies often find using hoogle or other search tools and is a huge trap. *Every* usage of the above can be replaced by using

fromMaybe :: a -> Maybe a -> a

which forces the user to provide a default value for the case where the Maybe a is a Nothing.

The idea would be to deprecate fromMaybe for 7.12 and remove it completely later.

Comments?

Erik

_______________________________________________ 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