mergify[bot] on master
Update scalafmt-core to 3.5.3 Merge pull request #346 from sc… (compare)
mergify[bot] on master
Update scalafmt-core to 3.5.2 Merge pull request #345 from sc… (compare)
mergify[bot] on master
Update discipline-core to 1.5.1 Merge pull request #344 from sc… (compare)
mergify[bot] on master
Update sbt-typelevel, ... to 0.… Merge pull request #343 from sc… (compare)
mergify[bot] on master
Update sbt-typelevel, ... to 0.… Merge pull request #342 from sc… (compare)
mergify[bot] on master
Update discipline-core to 1.5.0 Merge pull request #341 from sc… (compare)
mergify[bot] on master
Update scalacheck to 1.16.0 Merge pull request #340 from sc… (compare)
"org.typelevel" %% "cats-tagless-macros" % "0.12"
-Ymacro-annotations
FunctorK
... would it be fairly symmetrical?
Bifunctor
being something like F[_, _]
, and a BifunctorK
being for algebra types of the form A[ _[_, _]]
,mapK[G[_, _]](fk: F ~> G)
...
ApplyK
and Aspect
for my algebra? Can't auto-derive because both extend FunctorK and this leads to ambiguity.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
mapK
from the companion object or directly from the typeclass
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?
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?
mapK
is that it will call the service before mapping it, thus triggering the side effect
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.
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!
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)
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.
mapK
and co as needed when you pass arguments to your constructors.
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.