Remove redundant Functor constraint from StateT Applicative/Alternative instances

Edward Kmett ekmett at gmail.com
Tue Nov 22 08:56:12 UTC 2016


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 <baldurpet at gmail.com> 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
> 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/20161122/3c7139fa/attachment.html>


More information about the Libraries mailing list