https://kotlinlang.org logo
#arrow-contributors
Title
# arrow-contributors
j

Jannis

12/22/2019, 10:48 PM
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.
r

raulraja

12/22/2019, 11:05 PM
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
I suppose that signature reseembles a nested flatMap
j

Jannis

12/22/2019, 11:27 PM
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
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...
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...
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. 🤷
s

simon.vergauwen

12/23/2019, 12:01 PM
Yes,
AndThen
was introduced for those stack-safety issues 🙂
👍 1
2 Views