Cats: Is there interest in `cats-tagless` ?

[raulraja]

One of the frequent issues I see as a consultant in the Scala space is how teams adopting tagless final in their code base struggle with common things like:

• Getting an instance of their algebra implicitly Component[F] because of the related boilerplate necessary to expose them implicitly
• Composing interpreters with mapK and others.

A few libs out there like sphynx, maincoon, diesel and Freestyle provide facilities to fill some of the gaps but the panorama out there looks diverse and lots of boilerplate is still written in most places that don't use these libraries.

I believe it could be improved if cats provided a library with the purpose of facilitating the community a cohesive approach to solve some of the common issues users are facing when building apps and libs with a tagless style.

I'm not sure if this an issue that other people care about. I think having a lib under cats would make it easier to us consultants convincing companies out there to use this style now that cats-effect is in the raise and many are adopting typed FP.

If others where interested one of the questions I ask myself is if we can we do all this stuff without macros.

Thanks for listening! 🍻

Original twitter thread

// cc @LukaJCB @kailuowang @lloydmeta @peterneyens

[kailuowang]

If moving mainecoon to typelevel/cats-tagless can help improve FP Scala adoption I am all for it.

[LukaJCB]

Same for me and sphynx :)

[longcao]

I generally like the idea but would want to know what the scope of this could be... one of the appeals of tagless final to me has been not _needing_ an extra lib to make working with tagless final nicer, whereas when working with Free monads having the coproduct and algebra boilerplate and whatnot abstracted away was almost necessary after a certain project size.

Consider me a less opinionated voice though, I don't think the tagless final work I've done thus far have been that complicated 🙂.

[raulraja]

@longcao IMO there is still the boilerplate of exposing the algebra implicitly in the companion, creating mapK and other methods that are always the same and when all coded manually in complex code bases it adds unnecessary complexity because the implementation of the methods and implicits machinery it's always the same.

[raulraja]

@LukaJCB added sphynx to the original thread, sorry I missed it earlier

[raulraja]

@kailuowang I believe that would be awesome and a great foundation, thanks for offering that!

From the Freestyle side of things we feel the same way and would love to get rid of the tagless related macros in core.

[lloydmeta]

I've been happily using diesel in my own projects for a while now, but am happy to consolidate to improve the ecosystem.

Getting an instance of their algebra implicitly Component[F] because of the related boilerplate necessary to expose them implicitly

AFAIK, the main innovation that diesel has in this area is the aliasing-inscope-Component[F]-to-companion:

// Import companion-to-interpreter aliasing sugar
import Maths.ops._, Logger.ops._

def prog[F[_]: Monad: Maths: Logger](x: Int, y: Int): F[Int] = {
  for {
    p <- Maths.times(x, y)
    _ <- Logger.info(s"Product: $p")
    s <- Maths.add(x, y)
    _ <- Logger.info(s"Sum: $s")
    f <- Maths.add(p, s)
    _ <- Logger.info(s"Final: $f")
  } yield f
}

If that's something that is deemed useful, then I'm happy to contribute it to this new initiative 😄

[raulraja]

Perhaps we can get started with a design document where we outline the features and usage we'd like to achieve based on what the libs expose and try to come up with a coherent approach. Does that sound like a good start? Where would be a good place to host that and collaborate to get this rolling?

[kailuowang]

Perhaps we can get started with a design document where we outline the features and usage we'd like to achieve based on what the libs expose and try to come up with a coherent approach.

@raulraja TBH, I kind of feel that going back to the drawing board might be an overkill. Simply moving mainecoon to typelevel/cats-tagless and merge in utilities from Sphynx and Freestyle and the aliasing-inscope-Component[F]-to-companion from diesel would be a low hanging fruit. Just my 2 cents.

[raulraja]

@kailuowang sounds good, let's do that. The document was more of a wish list and description of what the lib does but not suggesting we start from scratch. We can take the approach you mentioned and look into the doc once we have the repo and the lib features merged in if needed.

[kailuowang]

@raulraja great. Let me propose it in the typelevel general gitter room.

[kubukoz]

Just an update: https://github.com/typelevel/cats-tagless

[kailuowang]

Thanks @kubukoz closing now.