Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 14 08:34

    joroKr21 on master

    Update sbt to 1.5.4 (#256) (compare)

  • Jun 14 08:34
    joroKr21 closed #256
  • Jun 14 07:36
    scala-steward opened #256
  • Jun 09 07:30

    larsrh on master

    Update sbt-scalajs, scalajs-lib… Merge pull request #255 from sc… (compare)

  • Jun 09 07:30
    larsrh closed #255
  • Jun 08 15:12
    scala-steward opened #255
  • Jun 02 07:06

    joroKr21 on master

    Update sbt-github-actions to 0.… (compare)

  • Jun 02 07:06
    joroKr21 closed #254
  • Jun 01 23:50
    scala-steward opened #254
  • Jun 01 16:33

    joroKr21 on master

    Update sbt-tpolecat to 0.1.20 (… (compare)

  • Jun 01 16:33
    joroKr21 closed #253
  • Jun 01 15:18
    scala-steward opened #253
  • Jun 01 10:12

    joroKr21 on master

    Update sbt to 1.5.3 (#252) (compare)

  • Jun 01 07:51
    scala-steward opened #252
  • May 31 12:29

    joroKr21 on master

    Update scala-compiler, scala-li… (compare)

  • May 28 13:40
    scala-steward opened #251
  • May 28 11:43

    joroKr21 on master

    Add ReaderT test demonstrating … (compare)

  • May 28 11:43
    joroKr21 closed #250
  • May 28 11:23
    joroKr21 assigned #250
  • May 28 11:23
    joroKr21 labeled #250
Soren
@srnb_gitlab
hmm
Ben Spencer
@dangerousben
is it / should it be possible to use autoFunctorK on algebras that return Resource[F]?
Ben Spencer
@dangerousben
ah... I suspect not because Resource.mapK requires an instance of Defer for the target functor?
Ben Spencer
@dangerousben
oh, and Applicative... G: Applicative[H] is pretty confusing
Georgi Krastev
@joroKr21
Yeah I think those restrictions are lifted in CE3
Ben Spencer
@dangerousben
oh nice
Keir Lawson
@keirlawson
I it possible to use cats-tagless to derive a FunctorK instance for a type you don't own?
Georgi Krastev
@joroKr21
Yes, definitely - as long as it's a trait with a type parameter F[_] that appears in covariant positions
You can use Derive.functorK (all derivations are available in that object)
Keir Lawson
@keirlawson
import cats.tagless._

@autoFunctorK
trait Foo[F[_], T] {
  def a(i: Int): F[T]
}
^ this is giving me Cannot expand @autoFunctorK with Scala 2.13.4, clearly something in my setup is messed up, anyone any ideas what it could be?
I'm using "org.typelevel" %% "cats-tagless-macros" % "0.12"
Keir Lawson
@keirlawson
ok so its me being a numpty :D
didn't have -Ymacro-annotations
though in my defence whilst the install instructions on the github mention this, those on the microsite do not
Georgi Krastev
@joroKr21
yep sorry about that and thanks for the PR :thumbsup:
Jonas Chapuis
@jchapuis
hey, how difficult would it be to add BiFunctorK and the corresponding derivation for algebras with two parameters?
Diego E. Alonso Blas
@diesalbla
@jchapuis What would be the key operation of that BiFunctorK ?
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) ...
Jonas Chapuis
@jchapuis
thanks, yeah so I thought, I might give it a shot. Indeed I would like to have it to "mapK" bifunctorial algebras
Jonas Chapuis
@jchapuis
well, not so easy. Simulacrum only support single-parameter type constructors, and cats FunctionK likewise is for unary parameter types, I can't express a natural transformation between bifunctors using it
Andrey Patseev
@patseev
Hey guys. How to solve the situation when I need both 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
Georgi Krastev
@joroKr21
Hmm good question - do you mean that you can't use them? I don't think deriving would be a problem.
Andrey Patseev
@patseev
Yeah, I meant that I can't use it due to ambiguity of FunctorK in the scope. Deriving works.
Georgi Krastev
@joroKr21
That's the same problem with Applicative and Traverse in cats
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
Andrey Patseev
@patseev
Gotcha. Thank you!
Ben Spencer
@dangerousben
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
Ben Spencer
@dangerousben
FunctorK[Foo[*[_], T forSome { type T }]] ?
Ben Spencer
@dangerousben
or does it generate a different FunctorK for each value of T?
Georgi Krastev
@joroKr21
@dangerousben it would generate a method implicit def functorK[T]: FunctorK[Foo[*[_], T]] = ???
Ben Spencer
@dangerousben
right, thanks
ivan-klass
@ivan-klass
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?
Georgi Krastev
@joroKr21
Hmm interesting, I never thought about it - do you want to give it a try?
Georgi Krastev
@joroKr21
I've released 0.14.0 with the SemigroupalK changes: https://github.com/typelevel/cats-tagless/releases/tag/v0.14.0
Brian P. Holt
@bpholt

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?

Georgi Krastev
@joroKr21
@bpholt I think mapK is enough - you just need def async[F[_]: Async]: Future ~> F if I understand correclty
Oh no wait, I guess the problem with mapK is that it will call the service before mapping it, thus triggering the side effect
Georgi Krastev
@joroKr21
I guess your best bet is Derive.readerT[Service, Future].mapK[F](provide(service)) where
def provide[F[_], R](service: R)(implicit F: Async[F]): ReaderT[Future, R, *] ~> F =
  λ[ReaderT[Future, R, *] ~> F](r => F.fromFuture(F.delay(r(service))))
Georgi Krastev
@joroKr21
I even made it into a test: #250
Brian P. Holt
@bpholt
Oh wow, that’s great. Thanks!
Brian P. Holt
@bpholt
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.
Mark
@Fristi
Cool
shapeless 3 has FunctorK deriving for case classes
Woop :)
But what's needed for traits? Guess it doesn't work