Add MonadError instance to StateT

[jserranohidalgo]

@non Proposal for ScalaCenter hackathon at Lambda World
If MonadError[?[_],E] is available for F[_], then we can give a MonadError[?[_],E] instance for StateT[F,S,?], for any F, S, E.

[adelbertc]

Duplicate of #1378

[non]

Makes sense to me. 👍

@adelbertc I wouldn't call this a duplicate -- I think it's unlikely we'll get all the MTL instances in one PR. Maybe we could make sub-issues for particular instances (or groups of instances) and then link them to #1378?

[adelbertc]

@non OK fair :-)

One thing I want to note is since this is related to MonadError/MTL, be cognizant of the issue still up in the air here: #1379 (comment)

[non]

Right! My sense is that if we get something soon we could merge it (and I could update it later) -- or if we get a change to the MTL encoding first, then we might need to update a future PR.

[jvican]

Hey @adelbertc and @non, would you mind labelling this as hackathon? 😄

[adelbertc]

@non On a related note have you thought about what the way forward should be? Your comment seems to imply an OK to move to the Scato encoding if someone did the work, or still unsure?

Alternatively, @paulp also suggested a better, language-level solution: https://twitter.com/extempore2/status/781996943207567360

[non]

@adelbertc So -- I'm a few hours away from giving a talk at Lambda World, so I'm a bit distracted.

I'm largely OK with type classes containing other type classes (rather than extending them) but given the potential loss of coherence I think I prefer a model where you might still just combine the Monad with something like MonadCombine, a la:

def something[F[_]: Monad: MonadCombine, A](fa: F[A]) = ...

I realize that looks somewhat bad, but I think it dodges the worst issues of composition (accessing the inner monad is somewhat inconvenient and ugly). It might seem like we lose coherence here, but we've already lost it, given that users could always write this:

def foo[F[_]: Monad, A](fa: F[A]) = ...
def bar[F[_]: MonadCombine, A](fa: F[A]) = ...

Any code that calls foo and bar with the same F is already risking incoherence.

I think if we go with a compositional encoding, we need extra laws to check that the "default" implicit space provides coherent instances. We also need to try to combine up with relatively clear principles why someone should (or should not) use this encoding. This encoding would make defining MTL instances a lot easier but I think that authors will still need to be sure that the default implicit search space is coherent and reasonable.

I'm pretty OK with using a different MTL encoding, but once something like Traverse is affected I start getting a bit nervous.

[adelbertc]

Oh that's right, ignore me, let's talk more afterwards :-)