Proposal to deprecate and then drop fromJust

[David Feuer]

It seems to me sensible to hope, ultimately, to offer four (or maybe
three) different classifications:

1. Known partial (e.g., a partial outermost pattern)
2. Suspected partial (GADTs, nested patterns, and calls to
known/suspected partial functions make it hard to tell)
3. Possibly partial (No obvious reason to suspect partiality, but not
proved total)
4. Known total (without any possibility of errors or non-termination)

Then programmers could annotate functions they believe should have at
least some level of totality confidence, and GHC will bark at them if
it disagrees. Perhaps there could also be a magical "I solemnly swear
this function is total" pragma as well.

On Tue, Feb 24, 2015 at 11:45 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> We are working on detecting partiality in pattern matching right now
>
> S
>
> |  -----Original Message-----
> |  From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 24 February 2015 15:02
> |  To: Herbert Valerio Riedel
> |  Cc: libraries at 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 <hvr at gnu.org>
> |  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 at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> |
> |  _______________________________________________
> |  Libraries mailing list
> |  Libraries at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries