Proposal to deprecate and then drop fromJust

David Feuer david.feuer at gmail.com
Tue Feb 24 19:59:30 UTC 2015


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.
On Feb 24, 2015 2:52 PM, "Edward Kmett" <ekmett at gmail.com> wrote:

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


More information about the Libraries mailing list