<div dir="auto">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 5, 2017 12:01 PM, "David Feuer" <<a href="mailto:david.feuer@gmail.com">david.feuer@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="auto">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 5, 2017 11:50 AM, "Mario Blažević" <<a href="mailto:blamario@ciktel.net" target="_blank">blamario@ciktel.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind <<a href="mailto:rf@rufflewind.com" target="_blank">rf@rufflewind.com</a> <mailto:<a href="mailto:rf@rufflewind.com" target="_blank">rf@rufflewind.com</a>>> wrote:<br>
<br>
    Rather than deprecating a function, it would be nice to have some sort<br>
    of {-# PARTIAL #-} pragma to warn the user that 'read' is a partial<br>
    function (and similarly for 'head', 'tail' and its friends), much like<br>
    how GHC already warns about partial case-blocks.  That being said,<br>
    it's<br>
    probably best to delay this until there is a way to explicitly turn of<br>
    the warnings individually at the call site for those who want<br>
    warning-free code.<br>
<br>
<br>
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.<br>
</blockquote>
<br>
I like this idea the best so far. Two more points:<br>
<br>
- 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" #-}<br>
- -fno-warn-partial should be called -Wno-partial to fit the other warning flags<br>
<br>
    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?<br>
<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
</blockquote></div></div>