Is there a reason `StateT<F, S, A>` is defin...

# arrow-contributors

[Jannis]

Is there a reason StateT<F, S, A> is defined with Kind<F, (S) -> Kind<F, Tuple2<S, A>>> ? The double Kind<F, *> are weird. I am currently rewriting some tests for higher coverage and noticed a bunch of failures with monad-applicative-consistency (monad derived ap doing different things than normal ap) and StateT is the last one that still fails.

[raulraja]

That is probably how it was originally and never was questioned. Feel free to propose any changes to the encoding if it does not make sense

[raulraja]

I suppose that signature reseembles a nested flatMap

[Jannis]

It currently leads to weird situations where flatMap will only map over top Kind<F> and flatMap on the bottom one, whereas ap calls map2 on the top one. This violates monad-applicative consistency laws. I am currently looking through cats source to see if they implement those methods any different

[Jannis]

By the looks of it they never explicitly define it so they probably just have ap derived from Monad which uses flatMap. So this is specific to our code. I'd like to know the rationale behind the double kinds, might be because scats StateT is actually IndexedStateT<F, S, S, A> and it needs it somehow. Even their docs refer to StateT as basically (S) -> Kind<F, Tuple2<S, A>>. Anyway it's getting a bit late, so I'll think about it some more tomorrow...

[Jannis]

https://github.com/typelevel/cats/commit/cbc001c1c34b47a99f1efeda22a2c060d3e2aba8

[Jannis]

It is apparently because of trampolining. As I have basically 0 experience there I am not going to change that... The interesting part is that we use State<S, A> == StateT<ForId, S, A> where as this note describes that as faulty. Haven't used State much on it's own so I don't know how stack safe it is, but I think we use AndThen internally anyway. For now I'll change the ap method to use flatMap, remove all of the other applicative stuff that is explicitly implemented to get the laws passing...

[Jannis]

StateT<ForId, S> is definitly stacksafe according to our monad laws stack-safety test. So we probably don't need the double Kind<F, *>, not gonna do too much to it either way, if it works, it works and using flatMap for ap is also fine anyway. 🤷

[simon.vergauwen]

Yes, AndThen was introduced for those stack-safety issues 🙂