cps-async-connect VS dotty-cps-async

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

Also, support for probability monad (https://github.com/jliszka/probability-monad ) is added to cps-async-connect. Now it is possible to do probabilistic programming in scala with direct style: https://github.com/rssh/cps-async-connect/blob/master/probability-monad/src/test/scala/cps/monads/probability/ProbabilityExamplesSuite.scala )

cps-connect-async: https://github.com/rssh/cps-async-connect

Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.

integration libraries (https://github.com/rssh/cps-async-connect ) for akka-stream, cats-effects, fs2, monix, scalaz and zio

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

dotty-cps-async: https://github.com/rssh/dotty-cps-async

Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.

This is a generic async/await transformer for scala3 which allows using effectful monads in the direct style. URL: (https://github.com/rssh/dotty-cps-async )

dotty-cps-async [rssh/dotty-cps-async ] with automatic coloring do something very similar in two steps. Automatic coloring defines implicit conversion F[A] => A as x => await(x)(m). The compiler inserts those awaits inside async blocks and then eliminates them later via cps-transform. Exists some limitations which we need to add for effect monads like IO (we don't want run effect twice and don't want to screw semantics of effects by extra memoizing). So, if your language has a possibility to implement effect monads, then you need a possibility to restrict using Flattenable.