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

[David Feuer]

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" <david.feuer at gmail.com> 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ć" <blamario at ciktel.net> wrote:
>
>> On 2017-01-05 11:22 AM, Kris Nuttycombe wrote:
>>
>>> On Thu, Jan 5, 2017 at 7:01 AM, Phil Ruffwind <rf at rufflewind.com
>>> <mailto:rf at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170105/d0fda0b5/attachment-0001.html>