I'll finish up tomorrow, unless anyone beats me to it.

As far as I can tell, ExceptT needs to have Apply implemented as ap so that the behaviour is consistent with bind, but this does mean that we have a Monad m constraint from Apply downwards now... but, I've just realised that the change I made to MaybeT to loosen the constraints suffers from the very problem I just fixed for ExceptT.

I'm not sure what to suggest, since it seems like this the right thing, since the difference is this: the m is run regardless of whether the value is Nothing / Left in the apply case, but not in the Monad case. Maybe there's some way to make bind behave the same as apply instead, but I'm not really sure what that means, and it might have negative consequences.

Without the looser constraints we can't have MonadPar instances for MaybeT and now ExceptT it would seem, but then maybe that is correct, since they "don't work properly" in parallel?

Maybe the answer is to use the Monad constrained versions and provide custom applicative newtyped versions for MonadPar?

Does it make sense to break up ComonadEnv and ComonadTraced too? What are examples of monads which have ask but not local etc.?

Why not

apply (ExceptT f) (ExceptT x) = ExceptT (lift2 ($) <$> f <*> x)

?

Do you mean they're not equal in terms of what gets evaluated? True, but they're observationally equivalent, right?

That is how I changed apply for MaybeT, and how it was for EitherT - that exact implementation is what #60 complains about.

Honestly I have no idea, I stared at it for quite a long time trying to figure out whether the extra m running mattered or not.

What do you mean when you say the m is run?

I mean, with the apply version the effects occur for both sides regardless of whether the left fails or succeeds... right?

I was going to put something together to try and prove whether it matters or not, but haven't gotten around to it yet.

(Trying now)

A good test would be something like forever in the MaybeT (Eff _) monad, I think.

Edit: I mean replicateA, sorry.

It sounds like there is an issue, but we can probably fix it with a newtype, either here (preferable) or in parallel. I would really like to be able to implement MonadPar for something related to ExceptT and MaybeT.

We can definitely define newtype(s) with the desired applicative behaviour, with the caveat that they'll behave in the above way. I think the example above settles the discussion over whether the ap approach is right or not here though, unfortunately.

Sounds good

I'd vote for putting those newtypes in Parallel, as they're probably not going to be that useful on the whole outside of that situation. Given that, I think this PR is done sans any further comments.

I'm fine with putting them in parallel. Can we please add ComonadTell though? It will be necessary to break things up in my pairings and day libraries when I implement a MonadTell instance for Co w.

That's supposed to come out of ComonadTraced right? It might need some refactoring if so, as it's already only made up of one function: track :: forall a. t -> w a -> a.

Ah ok, interesting. Sounds good then.