## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Jakub Kozłowski
@kubukoz
instead of Eq - and it's basically eqv x y = x.head == y.tail && (x.tail, y.tail).product.forall { case (a, b) => eqv(a, b) }
any better ideas?
funny thing is, it's divering for S = List but works fine for Option
if only this was possible: implicit def catsFreeEqForCofree[S[_], A : Eq](implicit S: Eq[Cofree[S, A]] => Eq[S[Cofree[S, A]]])
with implicit function types, who knows...
Jakub Kozłowski
@kubukoz
trait Eq[A]
trait X[A]

implicit val forXOfA: implicit Eq[Int] => Eq[X[Int]] = null
implicitly[implicit Eq[Int] => Eq[X[Int]]]
Alexander Konovalov
@alexknvl
you need quantified contexts
Jakub Kozłowski
@kubukoz
or this
Jakub Kozłowski
@kubukoz
looks like it
wonder if there's a mechanism already used in cats
Alexander Konovalov
@alexknvl
I doubt it.
considering there is no Forall
Jakub Kozłowski
@kubukoz
ohh
so with that in mind
implicit def forListOfA[A](implicit A: Eq[A]): Eq[List[A]] = ???
//here!
implicitly[implicit Eq[Int] => Eq[List[Int]]]
would it be the first or the second line that needed e.g. forall?
to me it looks like valid scala
it might even work if A: Eq[A] in the first line isn't marked implicit
aaaand the implicit keyword disappears in the second line
but that's just an implicit view then
Rob Norris
@tpolecat
@kubukoz you might look at how these are defined in matryoshka
Jakub Kozłowski
@kubukoz

so my reasoning for this working in dotty is that:
given

implicit def forList[A](A: Eq[A]): Eq[List[A]] = ???
implicitly[Eq[Int] => Eq[List[Int]]]

compiles in scala, then

implicit def forList[A]: implicit Eq[A] => Eq[List[A]] = ???
implicitly[implicit Eq[Int] => Eq[List[Int]]]

should also compile

@tpolecat I'll take a look (later), thanks
EqualT?
I was thinking about sth like trait EqK[F[_]] { def eqv[A](x: F[A], y: F[A]): Boolean } before
Jakub Kozłowski
@kubukoz
you know what, this could actually work... an EqK[F[_]], Eq[A] => Eq[F[A]] derivation would be trivial
or EqK could just be a type alias: type EqK[F[_]] = Eq ~> λ[α => Eq[F[α]]]
with a derivation of Eq: implicit def eqKToEq[F[_] : EqK, A : Eq]: Eq[F[A]] = implicitly[EqK[F]].apply(Eq[A])
and instead of defining an Eq[List[A]] we'd define EqK[List], and the rest would be done by the conversion
massive incompatibilities though... without breaking the best we could do is probably define EqK as a separate typeclass, and duplicate the instances for Option, List etc. (I guess)
WDYT?
Jakub Kozłowski
@kubukoz
still confused why Eq[Cofree[List, Int]] breaks and Eq[Cofree[Option, Int]]doesn't
ah, I know. It would, I was just checking in CofreeSuite where it's defined explicitly :joy:
Jakub Kozłowski
@kubukoz
oh, and it looks like we'd need the same for Order and Show...
Mateusz Górski
@goral09
Hi, I am confused about use case for MVar and Ref. Looking at their interface they both provide methods for get: F[A] and set/put(a: A): F[Unit]. Can't MVar in place of Ref? I understand that MVar can be used as a communication channel ( blocking on get and put ) which is not possible with Ref.
Derek Williams
@derekjw
@goral09 A Ref wont block on get, but an MVar might if no value is available. So an MVar cannot be used in place of a Ref if a value is always expected.
Fabio Labella
@SystemFw
@goral09 a very, very important difference is that modify on Ref is atomic
just to give a bit of perspective, Ref and Deferred are coming from fs2, MVar is coming from Monix (and of course from Haskell, although in Haskell you also have STM)
when designing the new concurrency scheme in fs2, I made a decision to not go with MVar, separating the functionality into Ref and Deferred instead

Can't MVar in place of Ref?

Anyway if you do set/put, it will break in the presence of concurrency

so use Ref.modify
a Ref is also lighter weight
Fabio Labella
@SystemFw
(I guess I should specify, take/put on MVar for modification does work, but you end up having to worry about the state of the MVar, whether empty or full, and are at risk of deadlock)
Jakub Kozłowski
@kubukoz
what's MVar useful for, then? (in Scala)
if there are so many drawbacks
Fabio Labella
@SystemFw
well, I'm biased obviously since I consciously used to not go there. I think when dealing with synchronisation it might give slightly more control than Ref + Deferred, however at the price of significantly increased complexity as a design tool