Add a ValidatedT to give ApplicativeError to any Applicative.

[johnynek]

currently it only has MonadError when F[_]: Monad but I think you can have ApplicativeError when F[_]: Applicative.

[peterneyens]

I think this again is because the ap defined using Applicative[F] is inconsistent with the one using Monad[F]. That is the reason why there is no Apply and Applicative for EitherT, which implies that ApplicativeError would suffer from the same problem, right?
See #1467 (comment) and the linked issues.

[LukaJCB]

I think for the same reason Haskell also only has
Monad m => Applicative (EitherT e m)

[johnynek]

I didn't know it was inconsistent. It's not obvious to me why we can't make it consistent, but no huge deal. We can convert to ValidatedT.

[johnynek]

actually, there is no ValidatedT.

[edmundnoble]

There is no ValidatedT? How so? Applicatives compose. ValidatedT[F, E, ?] would just be a wrapper on top of Nested[F, Validated[E, ?], ?], I believe.

[johnynek]

The point of ValidatedT, I think, is to get ApplicativeError from Applicative. You can't do that currently with Nested.

Maybe we want ApplicativeError on Nested[F, G, ?] if you have F[_]: Applicative and G[_]: ApplicativeError. Seems like you could also do the opposite perhaps: F[_]: ApplicativeError and G[_]: Applicative If true, it is not 100% clear which should be preferred.

I think an explicit ValidatedT offers some usability wins when the point is to add error handling to an Applicative.

[adelbertc]

I think there is no ValidatedT because that name invokes the idea of a monad transformer, which Validated cannot have. Of course as Edmund mentions you can have other effects composed with Validated through Nested.

Assuming the definition is general I could see such a Nested type class instance for ApplicativeError being useful. I wouldn't want to see a ValidatedT though since it would just be a special case of Nested and it would seem like we're privileging Validated. Maybe a type alias though if this is a common enough thing people want to do.

[johnynek]

There are a lot of utility methods, similar to what we have in EitherT that you would want. Like mapInvalid, isValid, etc... just using Nested means we don't have those.

[edmundnoble]

Applicative transformers seem to be just as useful a concept as monad transformers; I don't know if all applicatives actually admit ways to produce inductive instances for all applicative-focused MTL classes, and that is the chief use-case for monad transformers.

Additionally, I agree with @johnynek that unless we're going to provide a nicer syntax for Nested, applicative transformers do present a usability benefit.

Even more additionally, I'm sitting on the TwistedT applicative transformer until we have newtypes.

[leandrob13]

Is anyone working on this already?