Automatic colouring of effect monads.

[rssh]

blogged about the history there https://github.com/rssh/notes/blob/master/2021_06_27_automatic-coloring-for-effects.md

current rules [0.9.0-snaphot]:

• If some variable is used only in a synchronous context (i.e., via await), the macro will color it as synchronous (i.e., cached if used more than once).
• If some variable is passed to other functions as effect - it is colored as asynchronous (i.e., uncached).
• If the variable is used in synchronous and asynchronous contexts simultaneously, we can't deduce the programmer’s intention, and the coloring macro will report an error.
• If the variable, defined outside of the async block, is used in synchronous context more than once - the macro also will report an error.

[sideeffffect]

Hi, when I look at the Attempt 0 for "auto-coloring", it seems to me like the best solution to build on top of, the others seem to me like too magical.

What is the problem with "Attempt 0" is how heavy-weight the async(...) syntax is. One has to type async, the opening the brace, then important thing and then the closing brace. But isn't there a way to make the syntax more lightweight? For example, by using a unary prefix operator (like unary_!), that is short to write and doesn't require closing ). It would then look like

    val c = async[PureEffect] {
      val logger = ! PEToyLogger.make()
      val counter = ! PEIntRef.make(-1)
      while {
        val v = ! counter.increment()
        ! logger.log(v.toString)
        if (v % 3 == 0) then
           ! logger.log("Fizz")
        if (v % 5 == 0) then
           ! logger.log("Buzz")
        v < 10
      } do ()
      ! logger.all()
    }

What do you think? Btw, it kinda resembles F#'s computation expressions.

We could also use unary_~ for .use, in analogous way, as unary_! is used for .flatMap.

[rssh]

This is not about autoColoring.

It is possible to define something like

inline transparent unary_![F[_],T](ft:x[F[T](using CpsAwaitable[F]):T = await[F,T](x)

Why I'm not a big fan of this (although we can include shorthand syntax under some subpackage) is because the developer should make a decision, which can be made by computer. I.e. we force developers to do boring ineffective work with the possibility to create errors, just for something, which is trivial and has no relation to business logic.

Taking attention is the main work of the developer and the main currency of productivity. Exists theory, that the number of 'decisions per hour' is near-constant, regardless of the importance of these decisions. [Kahneman,[Attention and Effort] explains that there is a single pool of attentional resources]. I think in our case, this theory is not fully true (we can learn to do coloring 'automatically' on the brain level), but fact that extra symbols increase cognitive load during reading and writing looks apparent.

That's why I think, that the 'right' way is to solve the problem instead of minimizing it.
The final approach looks more or less safe: the developer can not remember rules, but if he/she will do something which potentially can be interpreted incorrectly - the compiler will report an error.

[rssh]

Also, it's a good idea to have a shortcut for await, enabled by some import. Question - What should be the package name?

//Thinking about

import cps.!.*

but afraid that it is hooliganism ;)

[sideeffffect]

What should be the package name?

A common name for these things is syntax, so

import cps.syntax.*

?

[sideeffffect]

What do you think about the .use (and corresponding unary_!)? Is that something a dotty-cps-async could do?

[rssh]

1. yes, syntax.* will be the best
   // define short syntax for async #44

2. Using from standard Scala library is fully supported
   (test, illustrating usage: https://github.com/rssh/dotty-cps-async/blob/master/shared/src/test/scala/cps/TestCBS1ShiftUsing.scala ).
   In theory, it can be with short syntax, from the other side - I have no seen much usage of this in programs (will recheck community corpus).
   If we will define given Using.Releasable[cats.Resource] - using with cats.Resource should just work. Not sure, if cats define one now.
   // check, that cats resoures are mapped to scala Using.Releasable cps-async-connect#2

3. Exists yet one interesting item, connected with .use - about having something like explicit scope operator, wich can be useful for cases like structured concurrency. This is on early stage and still unclear.

[rssh]

Automatic coloring was a maximum that was possible to achieve without the changes in the compiler.
Now, when we have a compiler plugin, automatic coloring can be deprecated in favor of direct context encoding.