I'm using
"org.typelevel" %% "cats-tagless-macros" % "0.12"
didn't have
-Ymacro-annotations
though in my defence whilst the install instructions on the github mention this, those on the microsite do not
I suppose you could just try copying and adapting the code of
FunctorK... would it be fairly symmetrical?
Bifunctor being something like F[_, _], and a BifunctorK being for algebra types of the form A[ _[_, _]] ,you may still have function
mapK[G[_, _]](fk: F ~> G) ...
Hey guys. How to solve the situation when I need both
I've kinda solved this by deriving
ApplyK and Aspect for my algebra? Can't auto-derive because both extend FunctorK and this leads to ambiguity.I've kinda solved this by deriving
Aspect and SemigroupalK instead and on "call-site" requiring FunctorK and SemigroupalK and re-implementing map2K manually there. But it's ugly and doesn't feel like a proper solution
I guess a workaround would be to use
mapK from the companion object or directly from the typeclass
It's not ideal
The former if you're using the macro annotations
in this first faq, what would the type of the generated FunctorK instance look like (in kind-projector syntax)? https://typelevel.org/cats-tagless/faq.html#does-cats-tagless-support-algebras-with-extra-type-parameters
Guys, perhaps I'm missing something, but out of curiosity, why does
autoSemigroupalK require all F[_] positions to be covariant? I think that given two algebras (say, algG: Alg[G], algH: Alg[H]) a product Alg[Tuple2K[G, H, *]] can handle input argument t2k: Tuple2K[G, H, A] with passing t2k.first to algG and t2k.second to algH correspondingly. Am I wrong with something here?
I've released 0.14.0 with the
SemigroupalK changes: https://github.com/typelevel/cats-tagless/releases/tag/v0.14.0
We have a lot of generated code for working with Thrift services that has a tagless-style trait with implementations in Twitter Futures. When we pull those into a cats-effect app, we’re writing a lot of boilerplate implementations that delegate the actual work to the Future-based impl, wrapping each of those calls in Async[F].async and Sync[F].delay.
Does that sound like the kind of thing that Aspect / Codomain could help with?
Oh no wait, I guess the problem with
mapK is that it will call the service before mapping it, thus triggering the side effect
FYI, we turned that ReaderT
provide idea into a little microlibrary that enables an asyncMapK[F]on an algebra. I’d love feedback, or even to merge it into cats-tagless itself, if that makes sense.
shapeless 3 has FunctorK deriving for case classes
Woop :)
But what's needed for traits? Guess it doesn't work
But I think we can port cats-tagless to Scala 3 and also add case class support via shapeless - it just won't be easy because the traits are the main use case and there we have to write macros
But maybe the AsyncFunctorK and stdlib instances could be added to a cats-tagless-effect or something, idk
hey guys, would you know why
implicit def loggerAutoDerive[F[_], G[_]](
implicit af: Logger[F],
functorK: FunctorK[Logger],
fk: F ~> G
): Logger[G] = functorK.mapK(af)(fk)works, but the more generic higher-kinded version of this:
implicit def autoDerive[F[_], G[_], Alg[_[_]]](
implicit af: Alg[F],
functorK: FunctorK[Alg],
fk: F ~> G
): Alg[G] = functorK.mapK(af)(fk)is diverging and I can't get it to work? I suppose that's why cats-tagless has that as a macro but was curious why the compiler isn't capable to resolve it. Thanks!
Hey @jchapuis let me try to explain. Let's say you want to summon
Alg[G] for some known Alg and G - for example Logger[IO]. The problems is that at this point the Scala compiler doesn't know what F is - it could be anything including IO itself. And if we assume it could be IO, then when we look for Alg[F] we are actually looking for Logger[IO] again which circles back to the same implicit autoDerive and we create a cycle. You could break this cycle if you reorder the implicit arguments like this:implicit def autoDerive[F[_], G[_], Alg[_[_]]](
implicit fk: F ~> G,
af: Alg[F],
functorK: FunctorK[Alg]
): Alg[G] = functorK.mapK(af)(fk)
This way
F can be determined before we look for Alg[F]. But now you need to be really careful what kind of implicit F ~> G transformations you have in scope (for example if you had IO ~> IO we would end up with the same problem.
Now I would go on a tangent and recommend that you don't do this at all :smile: - these complex implicit resolution problems are one valid criticism of tagless final in Scala and I would recommend that you go for a simpler approach where you pass your tagless final interfaces as regular constructor parameters. In a way that higher-level implementations depend on lower-level interfaces as constructor parameters. The only difference is that they are not implicitly resolved - you just do
mapK and co as needed when you pass arguments to your constructors.
Take for example
class CustomerEmailService[F[_]](customerRepository: Repository[F], emailClient: Client[F]) extends EmailService[F] - now you can do new CustomerEmailService(customerRepository.mapK(transactional: ConnectionIO ~> IO, emailClient.mapK(retrying: IO ~> IO)) etc. - note how retrying doesn't change the type. That would be hairy to make it work with implicits because of ambiguity.
3 replies