Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Drew Boardman
@drewboardman
well with Encoder you're right. If I want, say, 3 different codecs for DateTime in my application - then an instance of Encoder for DateTime isn't appropriate
Fabio Labella
@SystemFw
I'm not talking about Encoder either (that should just be explicit)
I"m talking about the other category, basically "effects"
like F[_]: Monad: Db: Cache (the latter two)
you want to pass them implicitly, because they are basically capabilities of your effect
Drew Boardman
@drewboardman

this is what I was referring to with orphaned-instance

only create them at call site, right before injection

that would require an orphaned instance, no?
Fabio Labella
@SystemFw
but create them explicitly, because there is no coherence implied, and because often creation itself is effectful
Drew Boardman
@drewboardman
what was the name of this pattern again? F[_]: Monad: Db: Cache
Fabio Labella
@SystemFw

that would require an orphaned instance, no?

well I guess, though typically the constructor is still in the companion object, and you can inject it by either making it implicit at call site, or by passing explicitly (which implicit args allow you to do)

Drew Boardman
@drewboardman
where I declare the instances that my typehole needs to abide to
Fabio Labella
@SystemFw
that pattern is an instance of final tagless encoding
but "capability classes" is more descriptive in some ways
Drew Boardman
@drewboardman
hmm I remember there being another term, but it's evading me
Fabio Labella
@SystemFw
since final tagless can be used for other things (which aren't effectful)
final tagless
or MTL style
they are all a bit imprecise
point being, haskell doesn't really have a good pattern for this
scala is more flexible
the closest thing in Haskell is the reflection package
Drew Boardman
@drewboardman
well haskell does declare TC instances that need to exist for datatypes
well thanks for the primer, that was useful. Would you recommend pivoting to SKunk?
i am indeed using psql
with doobie
Fabio Labella
@SystemFw
it's very new, so I don't know
doobie is still great, so there's no immediate reason to change

well haskell does declare TC instances that need to exist for datatypes

yeah but managing effectful abstraction in Haskell is still an open problem with like 10 competing solutions

Drew Boardman
@drewboardman

this is driving me crazy. The name was referring to

F[_]: Monad: Db: Cache vs passing them in the implicit parameter list (implicit etc etc)

Fabio Labella
@SystemFw
context bounds
but that's not the pattern
Drew Boardman
@drewboardman
yep context boundsa
that was the name
Fabio Labella
@SystemFw
it's just a feature which is true for A: Encoder as well
they are literally the same thing
Drew Boardman
@drewboardman
right, yeah
ty sir
Arulselvan Madhavan
@ArulselvanMadhavan
    val tags = (opt1, opt2) match {
      case (Some(l), Some(r)) => Some(l + r)
      case (Some(l), None) => Some(l)
      case (None, Some(r)) => Some(r)
      case (None, None) => None
    }
Is there a way to express this fallback logic using combinators that's easier to read without using pattern matching?
Adam Rosien
@arosien
<+> (combineK)
Michael Pilquist
@mpilquist
opt1 |+| opt2 assuming you have import cats.syntax.all._
Adam Rosien
@arosien
whoops
what :point_up: mp said
Arulselvan Madhavan
@ArulselvanMadhavan
Thank you!
Adam Rosien
@arosien
dang, should have gotten that one
Michael Pilquist
@mpilquist
|+| is syntax for cats.Semigroup[A].combine — there’s an Semigroup[Option[A]] any time there’s a Semigroup[A]
Arulselvan Madhavan
@ArulselvanMadhavan
Thanks. Good to know
vito-c
@vito-c
val fs = Future.successful("thing")
val fe:Future[Either[Int,String]] = fs.map(Right(_))
val fet:EitherT[Future,Int,String] = EitherT(fe)
val fft:EitherT[Future,Int,String] = EitherT(fs.map(Right(_))) // doesn't work
I feel like there is something I'm missing why doesn't fft work? Is there a way to get it working?

I'm pretty much only doing this for consistency

val c = EitherT(fs.map(_.asRight[Int]))

well answered my own question :D

matrixbot
@matrixbot

nalix > <@gitter_vito-c:matrix.org> ```

val fs = Future.successful("thing")
val fe:Future[Either[Int,String]] = fs.map(Right())
val fet:EitherT[Future,Int,String] = EitherT(fe)
val fft:EitherT[Future,Int,String] = EitherT(fs.map(Right(
))) // doesn't work
`` I feel like there is something I'm missing why doesn'tfft` work? Is there a way to get it working?

The problem is that Right won't widen to Either, which causes type inference to go awry. An easy fix is to use an extension method asRight from cats.syntax.either, which returns an instance of Either class, instead of the default Right constructor.