Re: Proposal to deprecate and then drop fromJust

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 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 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 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@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries