Tagless Final instead of hard-coded futures

I’ve been digging through the code a little and noticed that the direct use and execution of Futures brings some inconveniences with it:

• An ExecutionContext has to be passed everywhere.
• You can’t use other libraries like Monix to perform the execution.
• You can’t reflect on the execution (e.g. in what sequence is stuff done).
• Tests always have to await.

I was wondering if you have considered / would consider a Final Tagless encoding instead of direct use of futures?

[DougC]

For Field it might look like this:

case class Field[Ctx, Val, F[_] : Effect](...)

In fact, in most places you would not need to declare F[_] as an effect. So it might look like this:

case class Field[F[_], Ctx, Val](...)

cats-effect provides a number of type classes that describe the needed effect more granularly, e.g. Async, Sync, Concurrent. But even then, a lot of code only needs to declare F[_] to be something like Functor (if you use map) or Monad (if you use flatMap), etc.

Your point about how this looks to the user of the library is valid and something to consider. One approach could be to have the core library be parameterized on F[_], which would be compatible with http4s and other parts of the cats-effect ecosystem, and then provide a version of the types that are specialised to Future for backwards compatibility and easier use when integrating into, say, Play or Akka Http.

[nightscape]

I just stumbled upon another interesting use case, optimizing the execution: https://typelevel.org/blog/2017/12/27/optimizing-final-tagless.html The author @LukaJCB even mentions GraphQL as possible use case 😄