<p dir="ltr">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.</p>
<div class="gmail_quote">On Feb 24, 2015 2:52 PM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>It'd be a damn sight more work, but I think it'd be worth it.</div><div><br></div><div>This would let folks opt in or out, depending on which way we went to this extra social contract.</div><div><br></div><div>-Edward</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 2:32 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>-1</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>That said, I'd fully support putting in strong wording in the documentation about the partial nature of the function.</div><span><font color="#888888"><div><br></div><div>-Edward</div><div><br></div><div><br></div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 2:07 PM, Chris Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<blockquote>However, I think it'll require a very long deprecation
cycle before<br>
actually removing it from base, as 'fromJust' is officially part
of<br>
Haskell 2010, and there's probably a lot of code out there using<br>
'fromJust'...<br>
</blockquote></span>
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:<br>
<br>
1,176 instances of where fromJust is explicitly imported from
Data.Maybe<br>
7,431 instances of fromJust mentioned in a Haskell source file<br>
<br>
I'm in favour (+1) of the deprecation (warnings) cycle proposal
kicked around.<br>
<br>
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.<div><div><br>
<br>
<br>
<div>On 02/24/2015 04:54 AM, Michael Snoyman
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div dir="ltr"><br>
<br>
<div class="gmail_quote">On Tue Feb 24 2015 at 12:47:07 PM
Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On
2015-02-24 at 06:42:22 +0100, Erik de Castro Lopo wrote:<br>
> We currently have in the Data.Maybe module from base:<br>
><br>
> fromJust :: Maybe a -> a<br>
><br>
> which newbies often find using hoogle or other search
tools and is<br>
> a huge trap. *Every* usage of the above can be replaced
by using<br>
><br>
> fromMaybe :: a -> Maybe a -> a<br>
><br>
> which forces the user to provide a default value for
the case where<br>
> the Maybe a is a Nothing.<br>
><br>
> The idea would be to deprecate fromMaybe for 7.12 and
remove it<br>
> completely later.<br>
<br>
I'm +1 for deprecating (or attach a warning pragma to)
'fromJust' as<br>
I've been bit by 'fromJust' myself in the past, when I was
still mixing<br>
up 'fromMaybe' and 'fromJust'. Nowadays I don't reach out
for 'fromJust'<br>
anymore at all.<br>
<br>
However, I think it'll require a very long deprecation cycle
before<br>
actually removing it from base, as 'fromJust' is officially
part of<br>
Haskell 2010, and there's probably a lot of code out there
using<br>
'fromJust'...<br>
<br>
Relatedly, I was thinking of a separate 'partial-functions'
warning<br>
class, so we could annotate partial functions
(head/last/...) in base,<br>
and have the associated warnings be tunable via a separate
GHC -fwarn*<br>
flag. This could even be generalised to arbitrary
warning-classes:<br>
<br>
{-# WARNING[partial] fromJust "Use 'fromMaybe' instead" #-}<br>
<br>
I'm sure we would come up with other useful
warning-classes...<br>
<br>
<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Michael </div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span><pre>_______________________________________________
Libraries mailing list
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div>