More instances for monad transformers

[adelbertc]

e.g. If F[_]: Applicative we can't get Applicative[EitherT[F, ?], Error, ?] because the Applicative-specific instance doesn't exist. Similarly for F[_]: Apply, F[_]: Functor, etc.

[peterneyens]

There were some issues about Apply#ap and Monad#ap inconsistency for OptionT and EitherT (still XorT at that moment), see #1107 and scalaz/scalaz#255.

That is the reason I added toNested for both data types in #1172.

[kailuowang]

Sort of blocked by #1210

[kailuowang]

@adelbertc I might've misunderstood this issue. Does it include more MTL instances for Monad transformers?

[adelbertc]

Both MTL and non-MTL instances. I believe even right now, if F only has an Applicative instance (meaning it has no instance for any subclass of Applicative like Monad), then you cannot get an EitherT[F, E, ?].

[peterneyens]

Relevant for Applicative of EitherT: ekmett/either#38.

[kailuowang]

@peterneyens, so, according to the discussion in ekmett/either#38, if I understand correctly, to remain the MonadTransformer semantic we can't implement those instances without using the Monad of F for all MonadTransformers?

[peterneyens]

I think that discussion is only relevant for OptionT and EitherT.

For both OptionT and EitherT the Apply(similar for Applicative) instance you get for the transformer by using an Apply[F] instance, is inconsistent with the currently provided Monad instance of those transformers.

That is the reason for toNested on OptionT and EitherT (#1172), so you can get that ap if you want. The doctests of OptionT#toNested and EitherT#toNested have examples of the different ap behaviour.

Scalaz has the method app for OptionT and EitherT , and our EitherT seems to have applyAlt.

We encountered this while @yilinwei and I were working on adding the missing instances for OptionT(#1103) and XorT (at that time, #1106, #1106 (comment)).

So at least for OptionT and EitherT I think we have all the instances we can provide (apart of the "passing through" MTL instances).

[kailuowang]

So what's left? I only found one...but I probably didn't look closely enough.

• Applicative in StateT

[peterneyens]

I don't think you can implement Applicative[StateT[F, S, ?]] given an Applicative[F] as StateT.map2 uses FlatMap[F].

[kailuowang]

Right. Then I don't know what's left, you?

[adelbertc]

Oh that's annoying.. does it need FlatMap because of the way we encode StateT ? That double-nesting of F

[johnynek]

@adelbertc yes, I think it is due to the nesting, because after composing the function we have to flatten out the extra F[_]. I think it is kind of a shame that we have no way to have an applicative state.

[larsrh]

I'm going to close this for now. In case there are any concrete instances missing, let's open dedicated issues for that.