Remove redundant Functor constraint from StateT Applicative/Alternative instances

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

Remove redundant Functor constraint from StateT Applicative/Alternative instances

Baldur Blöndal
Does this belong here? Applicative [1] and Alternative [2] instances of StateT have redundant constraints

> instance (Functor m, Monad     m) => Applicative (StateT s m)
> instance (Functor m, MonadPlus m) => Alternative (StateT s m)

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

Re: Remove redundant Functor constraint from StateT Applicative/Alternative instances

Henning Thielemann

On Mon, 21 Nov 2016, Baldur Blöndal wrote:

> Does this belong here? Applicative [1] and Alternative [2] instances of StateT have redundant constraints
>
> > instance (Functor m, Monad     m) => Applicative (StateT s m)
> > instance (Functor m, MonadPlus m) => Alternative (StateT s m)
>
> The Functor constraint may be removed

Only since the AMP, i.e. GHC-7.10.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Remove redundant Functor constraint from StateT Applicative/Alternative instances

Edward Kmett-2
In reply to this post by Baldur Blöndal
They could be CPP'd around on newer versions, sure, at the cost of a fair bit of noise in the source code. Presumably it was considered simpler to just have one type signature. I've CC'd Ross Paterson, the maintainer of transformers. Ultimately it comes down to a 3 way decision between 1.) cleaner code by keeping the status quo, or 2.) cleaner haddocks by changing the code as requested here conditionally with CPP, or 3.) loss of backwards compatibility by just changing the type completely.

I don't particularly care which of the first two options are taken -- and the first even has the benefit of requiring zero labor -- but I think it'd be a bad idea to lose backwards compatibility by taking the third.

-Edward


On Mon, Nov 21, 2016 at 5:52 PM, Baldur Blöndal <[hidden email]> wrote:
Does this belong here? Applicative [1] and Alternative [2] instances of StateT have redundant constraints

> instance (Functor m, Monad     m) => Applicative (StateT s m)
> instance (Functor m, MonadPlus m) => Alternative (StateT s m)

_______________________________________________
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 redundant Functor constraint from StateT Applicative/Alternative instances

Baldur Blöndal
1) is good, I assume 3) will happen once the dust settles on AMP

2016-11-22 8:56 GMT+00:00 Edward Kmett <[hidden email]>:
They could be CPP'd around on newer versions, sure, at the cost of a fair bit of noise in the source code. Presumably it was considered simpler to just have one type signature. I've CC'd Ross Paterson, the maintainer of transformers. Ultimately it comes down to a 3 way decision between 1.) cleaner code by keeping the status quo, or 2.) cleaner haddocks by changing the code as requested here conditionally with CPP, or 3.) loss of backwards compatibility by just changing the type completely.

I don't particularly care which of the first two options are taken -- and the first even has the benefit of requiring zero labor -- but I think it'd be a bad idea to lose backwards compatibility by taking the third.

-Edward


On Mon, Nov 21, 2016 at 5:52 PM, Baldur Blöndal <[hidden email]> wrote:
Does this belong here? Applicative [1] and Alternative [2] instances of StateT have redundant constraints

> instance (Functor m, Monad     m) => Applicative (StateT s m)
> instance (Functor m, MonadPlus m) => Alternative (StateT s m)

_______________________________________________
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 redundant Functor constraint from StateT Applicative/Alternative instances

Ross Paterson-2
On Tue, Nov 22, 2016 at 09:17:32AM +0000, Baldur Blöndal wrote:
> 1) is good, I assume 3) will happen once the dust settles on AMP

Yes, there's a lot of conditional CPP in there already, but this doesn't
seem severe enough to justify more.

> 2016-11-22 8:56 GMT+00:00 Edward Kmett <[hidden email]>:
>
>     They could be CPP'd around on newer versions, sure, at the cost of a fair
>     bit of noise in the source code. Presumably it was considered simpler to
>     just have one type signature. I've CC'd Ross Paterson, the maintainer of
>     transformers. Ultimately it comes down to a 3 way decision between 1.)
>     cleaner code by keeping the status quo, or 2.) cleaner haddocks by changing
>     the code as requested here conditionally with CPP, or 3.) loss of backwards
>     compatibility by just changing the type completely.
>
>     I don't particularly care which of the first two options are taken -- and
>     the first even has the benefit of requiring zero labor -- but I think it'd
>     be a bad idea to lose backwards compatibility by taking the third.
>
>     -Edward
>
>
>     On Mon, Nov 21, 2016 at 5:52 PM, Baldur Blöndal <[hidden email]>
>     wrote:
>
>         Does this belong here? Applicative [1] and Alternative [2] instances of
>         StateT have redundant constraints
>
>         > instance (Functor m, Monad     m) => Applicative (StateT s m)
>         > instance (Functor m, MonadPlus m) => Alternative (StateT s m)
>
>         The Functor constraint may be removed
>
>         [1] https://hackage.haskell.org/package/transformers-0.5.2.0/docs/src/
>         Control.Monad.Trans.State.Lazy.html#line-201
>         [2] https://hackage.haskell.org/package/transformers-0.5.2.0/docs/src/
>         Control.Monad.Trans.State.Lazy.html#line-210
>
>         _______________________________________________
>         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