[Idea] Effect dedicated to idempotent operations

[sideeffffect]

We already have classes for effects

• Async, the most powerful kind, anything can happen
• IO, only synchronous effects can happen

Would it make sense to have an Effect which is only for operations which are idempotent. Those are operations where it doesn't matter if they're executed once, twice or n-times; it only matters if they're executed or not.

This class of effects would be subsumed by those above, I suppose. Or maybe just by Async (there can be async operations which are idempotent)?

[johnhungerford]

Are there any operations specific to idempotency that it would suspend? If not, it would simply track idempotency.

We might be able to make a generic effect-tracking type, which simply wraps other effects:

trait Tracked[S, Marked]:
  def tracked[A](effect: A < S)(using Tag[S], Tag[Marked]): A < Marked = ???
  def untracked[A, S1](effect: A < (Marked & S1))(using Tag[S], Tag[Marked]): A < (S & S1) = ???


trait Idem[-S]
class IdemConstructor[+S] extends Tracked[S, Idem[S]]

object Idem:
   def apply[A, S](effect: A < S): Idem[S] = Idem[S].tracked(effect)
   def handle[A, S, S1](effect: A < (Idem[S] & S1)): A < (S & S1) = Idem[S].untracked(effect)

[sideeffffect]

Interesting! Maybe this same mechanism could be also used to track Transaction effect as I've sketched over here

• [Idea] Effect dedicated to general transaction, subsuming STM and Relational DBs #932

Open question is, what should be the relationship between Idempotent and Transaction.

[fwbrasil]

I can't form a good picture of how this would be useful yet. Would it make sense to extend the effect to handle both idempotent and reversible computations? I think the bundle could be more useful. The evaluation of the computation could use this information to handle safe retries and rollbacks. It could enable implementing the saga pattern for example.

[sideeffffect]

Would it make sense to extend the effect to handle both idempotent and reversible computations?

Maybe? But I think they are different. There are computations that are idempotent, but not reversible. And vice versa. E.g. computation "Ensure the missile Xyz is launched".

[fwbrasil]

The same effect could handle both:

opaque type Rerunnable = ..
object Rerunnable:
    def idempotent[A, S](v: A < S) : A < (S & Rerunnable) = ...
    def reversible[A, S, S2](v: A < S)(reverse: => Unit < S2): A < (S & S2 & Rerunnable) = ...

It's interesting that Resource.acquireRelease can already be used to implement reversible computations.

I'm still having trouble to see how a new effect would be useful. Just tracking Rerunnable isn't very valuable since the computation could perform arbitrary side effects and freely introduce Rerunnable via effect widening. Something we could try is restricting Rerunnable.run to not accept a pending IO but that would rule out other effects based on it like Async.

[sideeffffect]

I'm still having trouble to see how a new effect would be useful.

It can be very useful for a user of Kyo to ensure that certain parts of their program is idempotent. Or that some parts are repeatable. Or that some parts are running within a transaction. Those are very interesting properties which programmers are interested in and they can exploit those properties to their advantage.

I don't think every Kyo users would use these distinctions all the time. But I think there could be great utility and thus demand. None of the other tools (ZIO, Cats Effect, ...) allow you to do that.

not accept a pending IO but that would rule out other effects based on it like Async

Indeed, idempotent program can be composed only of other idempotent programs (+ pure functions, of course).