WIP: Law checking & extending IOEffect typeclasses

[benhutchison]

This issue is to track some experimental hacking Ive been doing around

• Supporting the ConcurrentEffect typeclass from cats.effect 0.10 in IOEffect. This is a very speculative, "follow-the-types" implementation and I don't feel confident of its correctness or even sanity - any feedback most welcome. There's some gnarly transient mutable state to work around runIOs inablity to thread non-Unit values down the chain, inspired by @etorreborre hint on gitter last Nov

• Law checking of the Async instance and this new ConcurrentEffect using Discipline. On the laws branch, cats/test now runs law checks. One finding was that the existing Async fails 10 law checks, once around stack safety and nine times around seemingly not suspending thrown Throwables.

The story behind why I got interested in this area is that I will teach a second Eff workshop at Lambdajam this year. I want to update my material and try to teach whatever is contemporary "best-practice" as at 2018, and I think using cats.effect.IO with Eff would be a nice touch.

However that said, Ive already got the IO effect working fine inside Eff stack, so getting these typeclasses law-checked/working is perhaps a bad habit of looking down passing rabbit-holes :P

CC @alexandru

[benhutchison]

OK, Ive not made enough progress today and have hit the limits of what my knowledge & timebox can deliver. Closing this issue, reopen if I learn something that can unblock.

Concurrent law checks enabled, shows many are failing.

Earlier issues with Async laws were resolved with a better Eq check. Its still failing stack safety, related to typelevel/cats-effect#42

[etorreborre]

Stack safety issues might be related to the fact that I couldn't implement it properly for Eff. I think a proper implementation. I think the correct implementation would go along the lines of FreeApplicative which is quite involved.

[alexandru]

The stack safety laws are pretty severe — being required for both left-associated and right-associated flatMap chains, and also for map in recursive data structures too.

Sometimes I wonder if maybe they are too severe, but then there are instances in which we really need it (e.g. with map at least I've got the use-case in Iterant where if map isn't stack-safe, most operations could blow up with stack overflow errors for strictly initialized streams).

I don't know if it helps, not familiar with your implementation, but make sure to checkout the shenanigans we now have in:

• IndexedStateT: Fix #2186: make IndexedStateT stack safe typelevel/cats#2187
• Kleisli: Fix #1733: make Kleisli.flatMap stack safe typelevel/cats#2185

Also note that the laws need validation. Concurrent is very fresh for example, so when a law is failing try to understand why it fails and if that's fair or not — some laws might have assumptions about the execution model in them that we aren't aware of. It happened before, coming to light after I implemented Async for Iterant for example, which led to patching the laws to be more relaxed.

It's basically an ongoing process with those laws, so feedback is appreciated.