Jannis
11/06/2019, 7:21 PMSchedule
datatype that will enable users to easily express all sorts of retry/repeat strategies and I am at the point of choosing where to add the retry/repeat methods. Since the whole thing involves delay I was thinking Async or above (using delay
from coroutines), but then I saw the Timer
interface which offers some sort of sleep method for Concurrent
and some other implementations for rx2 and reactor. So the question is, where does this go in the typeclass hierarchy?raulraja
11/06/2019, 7:22 PMsimon.vergauwen
11/07/2019, 8:26 AMTimer
is a separate typeclass because Async
is not needed for a datatype to sleep
.
- Concurrent
can derive Timer
, so all it’s syntax is enabled in Concurrent
typeclass and it has a timer()
function that returns the derived instance.
I’ll try to take a good look @ the Schedule
PR asap, and we can discuss further there.Jannis
11/07/2019, 12:36 PMsimon.vergauwen
11/09/2019, 12:01 PMTimer
+ Monad
which you already have from MonadDefer
.F
using typeclasses. That means you can have a more general Schedule
which is not bounded to F
.
fun <F, A> Kind<F, A>.retry(schedule: Schedule, T: Timer<F>, M: Monad<F>: Kind<F, A> = ...
fun <F, A> Kind<F, A>.retry(schedule: Schedule: C: Concurrent<F>): Kind<F, A> = retry(schedule, C.timer(), C)
Jannis
11/09/2019, 7:30 PMsimon.vergauwen
11/09/2019, 7:31 PMSchedule
not just a data type that defines how to retry? Even if it needs to run any effects to calculate the next retry you could defer that and run that effect within F
using the typeclasses, no?Jannis
11/09/2019, 8:27 PM