Remove MonadFail (ST s) instance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Remove MonadFail (ST s) instance

Oleg Grenrus
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.html 
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

David Feuer
I'm pretty sure this has been discussed before. I have no idea what the resolution was.

On Sun, Nov 24, 2019, 10:57 AM Oleg Grenrus <[hidden email]> 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.html
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Vanessa McHale-2
In reply to this post by Oleg Grenrus
I like this idea

Cheers,
Vanessa

On 11/24/19 9: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.html
> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Henning Thielemann
In reply to this post by Oleg Grenrus

On Sun, 24 Nov 2019, Oleg Grenrus wrote:

> 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.

sounds reasonable
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Dan Burton
In reply to this post by Oleg Grenrus
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 <[hidden email]> 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.html
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

David Feuer
How do you deprecate an instance?

On Sun, Nov 24, 2019, 12:18 PM Dan Burton <[hidden email]> 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 <[hidden email]> 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.html
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Dan Burton
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.

Unfortunately, both of these options would require implementation in ghc, which is more complex than just changing the library definitions.

-- Dan Burton


On Sun, Nov 24, 2019 at 9:20 AM David Feuer <[hidden email]> wrote:
How do you deprecate an instance?

On Sun, Nov 24, 2019, 12:18 PM Dan Burton <[hidden email]> 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 <[hidden email]> 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.html
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Henning Thielemann

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Haskell - Libraries mailing list
In reply to this post by Oleg Grenrus
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...)

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.html
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Henning Thielemann

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Oleg Grenrus

It is.

-- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/Control.Monad.Fail.html#line-80
instance MonadFail IO where
    fail = failIO

-- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.html#failIO
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.html#ioException
ioException     :: IOException -> IO a
ioException err = throwIO err

-- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.Exception.html#ioError
ioError         :: IOError -> IO a
ioError         =  ioException

-- https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.IO.html#throwIO
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Haskell - Libraries mailing list
In reply to this post by Henning Thielemann
> > 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) ?

Oh right. I guess the IO instance is okay then.

Thanks for the correction,

Bertram
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Oleg Grenrus
In reply to this post by Haskell - Libraries mailing list
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:

> 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...)
>
> 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.html
>> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove MonadFail (ST s) instance

Andrew Martin
I'm also in favor of removing this instance. Since there is currently no deprecation mechanism for instances, I think it should simply be removed in GHC 8.12.

On Mon, Nov 25, 2019 at 7:14 AM Oleg Grenrus <[hidden email]> wrote:
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:
> 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...)
>
> 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.html
>> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


--
-Andrew Thaddeus Martin

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Instance warnings [Re: Remove MonadFail (ST s) instance]

Andreas Abel
In reply to this post by Henning Thielemann
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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Instance warnings [Re: Remove MonadFail (ST s) instance]

Ryan Trinkle-3
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Instance warnings [Re: Remove MonadFail (ST s) instance]

Oliver Charles-3
In reply to this post by Andreas Abel
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 <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Instance warnings [Re: Remove MonadFail (ST s) instance]

David Feuer
That definitely sounds like a good approach to me!

On Mon, Nov 25, 2019, 5:04 PM Oliver Charles <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Instance warnings [Re: Remove MonadFail (ST s) instance]

Oliver Charles-3
Perhaps I have found motivation for my first proposal!

On Mon, Nov 25, 2019 at 10:06 PM David Feuer <[hidden email]> wrote:

>
> That definitely sounds like a good approach to me!
>
> On Mon, Nov 25, 2019, 5:04 PM Oliver Charles <[hidden email]> 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 <[hidden email]> 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
>> > > [hidden email]
>> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> > _______________________________________________
>> > Libraries mailing list
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Instance warnings [Re: Remove MonadFail (ST s) instance]

George Wilson
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 <[hidden email]> wrote:

>
> Perhaps I have found motivation for my first proposal!
>
> On Mon, Nov 25, 2019 at 10:06 PM David Feuer <[hidden email]> wrote:
> >
> > That definitely sounds like a good approach to me!
> >
> > On Mon, Nov 25, 2019, 5:04 PM Oliver Charles <[hidden email]> 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 <[hidden email]> 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
> >> > > [hidden email]
> >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> > _______________________________________________
> >> > Libraries mailing list
> >> > [hidden email]
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> _______________________________________________
> >> Libraries mailing list
> >> [hidden email]
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
12