typelevel/cats-tagless

Georgi Krastev

@joroKr21

Also I wonder why F[Stream[F, ...]] - is there any reason not to flatten the outer F into Stream[F, ...]?

Mark de Jong

@Fristi

That works!

  implicit def stream[A]: FunctorK[({type L[F[_]] = Stream[F, A]})#L] = new FunctorK[({type L[F[_]] = Stream[F, A]})#L] {
    def mapK[F[_], G[_]](af: Stream[F, A])(fk: F ~> G): Stream[G, A] = af.translate(fk)
  }

Mark de Jong

@Fristi

With kind projector notation the scala compiler crashes

Mark de Jong

@Fristi

Hmm weird. I've got an interface PostgresRepos which is a collection of repositories:

trait PostgresRepos[F[_]] {
  def depots: DepotRepository[F]
  def tours: TourRepository[F]
}

this works:

  def weaveTraceData[F[_]](alg: PostgresRepos[F]): PostgresRepos[Aspect.Weave.Codomain[F, TraceData, *]] =
    new PostgresRepos[Codomain[F, TraceData, *]] {
      def depots: DepotRepository[Codomain[F, TraceData, *]] = Derive.aspect.weave(alg.depots)
      def tours: TourRepository[Codomain[F, TraceData, *]] = Derive.aspect.weave(alg.tours)
    }

This doesn't:

  def weaveTraceData[F[_]](alg: PostgresRepos[F]): PostgresRepos[Aspect.Weave.Codomain[F, TraceData, *]] =
    Derive.aspect.weave(alg)

It bails on Type parameter F can only occur as a top level return type in method tours

When I flip the tours and depots line in my interface of PostgresRepos it complains about depots

Georgi Krastev

@joroKr21

Yes, that's a limitation of the implementation

Hope the error message is clear

I'm not sure if it can be lifted, we can think about it

Georgi Krastev

@joroKr21

Note that Derive.aspect does more than the Codomain

Georgi Krastev

@joroKr21

But if you can mechanically implement that instance then we should be able to automate it as well

Mark de Jong

@Fristi

I see, so defining weave instances for all repos? And then use Derive.aspect?

Georgi Krastev

@joroKr21

wdym?

Mark de Jong

@Fristi

Each repository has companion object with an instance of the aspect

By the way, do you think the aspect weaving is in good shape? I'm already using it, thinking about write a blog about it

Georgi Krastev

@joroKr21

Yes I think it's in good shape

Georgi Krastev

@joroKr21

@/all finally released 0.12 with lots of new features but Scala 2.11 is no longer supported: https://github.com/typelevel/cats-tagless/releases/tag/v0.12

Mark de Jong

@Fristi

Nice! Thanks for the release :tada:

I've been thinking.. what would you think of including annotations in the aspect weave?

Such that additional meta data can be attached to a function

It's almost reflection based programming :see_no_evil:

Georgi Krastev

@joroKr21

Annotations are really complicated - you also have type and term annotations, they can have arguments of their own

Mark de Jong

@Fristi

Oh that sounds complicated indeed, just tossing the idea :) Maybe someday

Soren

@srnb_gitlab

"An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specified by aspects (isolated representations of significant concepts in a program) and generate the final implementation code."

This sounds really cool

ritschwumm

@ritschwumm

@srnb_gitlab AOP is just a generalized COME FROM :)

Soren

@srnb_gitlab

I don't know what that is either :sweat_smile: @ritschwumm

ritschwumm

@ritschwumm

@srnb_gitlab GOTO's even more evil twin, see https://en.wikipedia.org/wiki/COMEFROM

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

typelevel/cats-effect#1285

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

Where communities thrive

People

Repo info

Activity