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

[Edward Kmett]

There is a rather broad continuum of notions of partiality you might want
to capture in such an annotation.

Possible non-termination is a form of partiality after all.

> length (cycle [1])

We don't have (or even necessarily want) a sufficiently nuanced fancy
dependent type system that all such notions of partiality can (or should)
be stomped out.

-Edward

On Thu, Jan 5, 2017 at 12:06 PM, David Feuer <david.feuer at gmail.com> wrote:

> 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
>>>
>>
> _______________________________________________
> 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/06e44b42/attachment.html>