FreeT is stack-unsafe

[djspiewak]

...somehow.

	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)
	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)
	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)
	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)
	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)
	at cats.free.FreeT.$anonfun$step$1(FreeT.scala:163)
	at scala.Function1.$anonfun$andThen$1(Function1.scala:85)

That goes on for a while and turns into an SOE. Staring at the source code, it looks like a recursive flatMap is causing it, but it's hard to say exactly.

[alissapajer]

Exciting! Do you have a reproduction?

[djspiewak]

Nothing minimized! I did discover it was a straight-up recursive definition though. I'm guessing that it's a left-associated bind where the recursion is on the left side. That's something that FreeT should still be fine with, but apparently it isn't handling that case (or something like it) very well.