How do you deprecate an instance? On Sun, Nov 24, 2019, 12:18 PM Dan Burton wrote:

If someone depends on this behavior, we should give them the courtesy of a proper deprecation cycle to aid them in fixing their code. That's what a deprecation cycle is for. Don't skip it.

-- Dan Burton

On Sun, Nov 24, 2019 at 7:57 AM Oleg Grenrus wrote:

...

I cannot see any justification for that instance

-- | @since 4.11.0.0 instance Fail.MonadFail (ST s) where fail s = errorWithoutStackTrace s

If someone wants to fail pattern matches in `ST s`, please do that explicitly.

I suggest and propose the removal without any deprecation period. If someone depends on this behavior, they ought to fix they code immediately: it's straight forward compiler type-error driven refactoring.

Note: compatibility package

https://hackage.haskell.org/package/fail-4.9.0.0/docs/Control-Monad-Fail.htm... doesn't have that instance, so I suspect not-that many use(d) that instance.

Discussion period: 2 weeks (until Monday 2019-12-09).

- Oleg

P.S. you might run into problems with https://gitlab.haskell.org/ghc/ghc/issues/15681 bug/miss-feature, but there's always a workaround to write code using explicit matching combinator, so it's not a show stopper.

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

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

On Sun, 24 Nov 2019, Dan Burton wrote:

We're talking about an instance in `base`, so if there's no other way, it could at least be a flag akin to -Wmissing-monadfail-instances that gets included in -Wcompat. But relatedly: should there be a way to deprecate instances? I would say yes.

Sounds like another application of instance warnings that we already talked about: https://gitlab.haskell.org/ghc/ghc/issues/11796

Having a deprecation path for instances would be hugely useful. It'd also be extremely useful to be able to do other refactors with typeclasses, such as splitting or merging them, perhaps using constraint synonyms. On Mon, Nov 25, 2019 at 11:28 AM Andreas Abel wrote:

Derailing... Incidently, I recently asked for a "instance warning" feature in GHC:

https://gitlab.haskell.org/ghc/ghc/issues/17485

(In my case I could go with a TypeError constraint instead.)

Maybe instance warnings could be a useful feature. It could be implemented along the TypeError mechanism.

On 2019-11-24 18:35, Henning Thielemann wrote:

...

On Sun, 24 Nov 2019, Dan Burton wrote:

...

We're talking about an instance in `base`, so if there's no other way, it could at least be a flag akin to -Wmissing-monadfail-instances that gets included in -Wcompat. But relatedly: should there be a way to deprecate instances? I would say yes.

Sounds like another application of instance warnings that we already talked about: https://gitlab.haskell.org/ghc/ghc/issues/11796 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

That definitely sounds like a good approach to me! On Mon, Nov 25, 2019, 5:04 PM Oliver Charles wrote:

I wonder if like TypeError we could have TypeWarning? Then you could have something like

instance TypeWarning "Please use Fooble instead" => Show Foo where

which would compile, but produce a warning whenever the `Show Foo` constraint was solved?

On Mon, Nov 25, 2019 at 4:28 PM Andreas Abel wrote:

...

Derailing... Incidently, I recently asked for a "instance warning" feature in GHC:

https://gitlab.haskell.org/ghc/ghc/issues/17485

(In my case I could go with a TypeError constraint instead.)

Maybe instance warnings could be a useful feature. It could be implemented along the TypeError mechanism.

On 2019-11-24 18:35, Henning Thielemann wrote:

...

On Sun, 24 Nov 2019, Dan Burton wrote:

...

We're talking about an instance in `base`, so if there's no other way, it could at least be a flag akin to -Wmissing-monadfail-instances that gets included in -Wcompat. But relatedly: should there be a way to deprecate instances? I would say yes.

Sounds like another application of instance warnings that we already talked about: https://gitlab.haskell.org/ghc/ghc/issues/11796 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

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

Some kind of instance warning like this would enable library authors to migrate type class instances. The Core Libraries Committee would likely be able to use this for good. I would definitely like to see that happen. Type class instances are "stuck" in Haskell today. On Tue, 26 Nov 2019 at 08:10, Oliver Charles wrote:

Perhaps I have found motivation for my first proposal!

On Mon, Nov 25, 2019 at 10:06 PM David Feuer wrote:

...

That definitely sounds like a good approach to me!

On Mon, Nov 25, 2019, 5:04 PM Oliver Charles wrote:

...

I wonder if like TypeError we could have TypeWarning? Then you could have something like

instance TypeWarning "Please use Fooble instead" => Show Foo where

which would compile, but produce a warning whenever the `Show Foo` constraint was solved?

On Mon, Nov 25, 2019 at 4:28 PM Andreas Abel wrote:

...

Derailing... Incidently, I recently asked for a "instance warning" feature in GHC:

https://gitlab.haskell.org/ghc/ghc/issues/17485

(In my case I could go with a TypeError constraint instead.)

Maybe instance warnings could be a useful feature. It could be implemented along the TypeError mechanism.

On 2019-11-24 18:35, Henning Thielemann wrote:

...

On Sun, 24 Nov 2019, Dan Burton wrote:

...

We're talking about an instance in `base`, so if there's no other way, it could at least be a flag akin to -Wmissing-monadfail-instances that gets included in -Wcompat. But relatedly: should there be a way to deprecate instances? I would say yes.

Sounds like another application of instance warnings that we already talked about: https://gitlab.haskell.org/ghc/ghc/issues/11796 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

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

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

It is. -- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/Control.Monad.Fai... instance MonadFail IO where     fail = failIO -- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.html#failI... failIO :: String -> IO a failIO s = IO (raiseIO# (toException (userError s))) Compare to -- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Exception.... ioException     :: IOException -> IO a ioException err = throwIO err -- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Exception.... ioError         :: IOError -> IO a ioError         =  ioException -- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.html#throw... throwIO :: Exception e => e -> IO a throwIO e = IO (raiseIO# (toException e)) - Oleg On 25.11.2019 13.37, Henning Thielemann wrote:

On Mon, 25 Nov 2019, Bertram Felgenhauer via Libraries wrote:

...

Oleg Grenrus wrote:

...

I cannot see any justification for that instance

    -- | @since 4.11.0.0     instance Fail.MonadFail (ST s) where         fail s = errorWithoutStackTrace s

It's certainly not in the spirit of the MonadFail proposal. Arguably, *all* implementations of `fail` in terms of `error*` are wrong, even the one for IO. (I suspect dropping the instance for IO would cause a lot of pain though...)

Isn't fail in IO a synonym for (ioError . userError) ?

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

As replied by Henning, fail @IO = throwIO . userError, which isn't throwing a pure exception. The IO instance is in the spirit of MonadFail proposal, it behaves well. If you write GHC-7.10..GHC-8.x code, you **should** depend on `fail` package, to get MonadFail class for GHC-7.x. See https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Adaptingoldcode On 25.11.2019 12.28, Bertram Felgenhauer via Libraries wrote:

...

I cannot see any justification for that instance

    -- | @since 4.11.0.0     instance Fail.MonadFail (ST s) where         fail s = errorWithoutStackTrace s It's certainly not in the spirit of the MonadFail proposal. Arguably, *all* implementations of `fail` in terms of `error*` are wrong, even

Oleg Grenrus wrote: the one for IO. (I suspect dropping the instance for IO would cause a lot of pain though...)

I'm neutral on the proposal itself.

...

If someone wants to fail pattern matches in `ST s`, please do that explicitly. However, I don't like this framing. In practice, there's at least one other use of MonadFail for historical reasons: generic code that may fail. Before MFP, one could write (and people have written) code like

fooM :: Monad m => a -> m b fooM ... = fail "unsupported case"

It is easy enough to change the signature of such a `fooM` to require MonadFail, but then the function becomes impossible to use for monads that don't have a MonadFail instance. So after the MFP, one should provide two functions instead, one using `error` and another one using `fail`...

...

Note: compatibility package https://hackage.haskell.org/package/fail-4.9.0.0/docs/Control-Monad-Fail.htm... doesn't have that instance, so I suspect not-that many use(d) that instance. Or perhaps nobody cares about ghc-7.10 anymore.

Cheers,

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

do we have a tracking ticket on gitlab for this? On Tue, Nov 26, 2019 at 4:28 AM chessai . wrote:

+1 on removal

On Tue, Nov 26, 2019, 4:04 AM Matthew Farkas-Dyck wrote:

...

+1 from me, this instance is insane _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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