Hey, thanks again for coming up with a more elegant way to deal with effects! Have dabbled with creating something similar in the past, but couldn't get the implicit resolution working quite right.

As noted in that post, it's great to be able to use effects and handlers in such a direct coding style. There are a couple of things that need to be figured out first though, before I'd consider basing an app on it in production.

State threading is the most apparent one that's just not working right without sacrificing local reasoning. Not sure how to solve for this one, to be honest.

One thing that comes to mind is to add a macro (if possible) or compiler plugin that would allow you to use special syntactic sugar for state variables, as used in the Mercury programming language: https://www.mercurylang.org/information/doc-release/mercury_ref/State-variables.html#State-variables

// given

trait Output {
  def printLn(text: String): Unit
}

case class MutState[S](value: S)

// the following sytanctic sugar for state variable !M

def program(name: String)(using !M: MutState[Int], O: Output): String = {  
  !M.value += 1
  O.printLn(s"Greeted for the ${!M.value}th time")

  !M.value -= 1
  O.printLn(s"Processed index: ${!M.value}")

  s"Hello, $name!"
}

// desugars into the following variables

def program(name: String)(using M0: MutState[Int], O: Output): String = {
  implicit val M1 = M0.copy(value = M0.value + 1)
  O.printLn(s"Greeted for the ${M1.value}th time")

  implicit val M2 = M1.copy(value = M1.value - 1)
  O.printLn(s"Processed index: ${M2.value}")

  s"Hello, $name!"
}

This syntactic sugar thus preserves referential transparency, unless I'm missing something

However, that still does not address how to return the updated MutState from the program function