Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html
trait EqK[F[_]] { def eqv[A](x: F[A], y: F[A]): Boolean }
before
EqK
could just be a type alias: type EqK[F[_]] = Eq ~> λ[α => Eq[F[α]]]
Eq
: implicit def eqKToEq[F[_] : EqK, A : Eq]: Eq[F[A]] = implicitly[EqK[F]].apply(Eq[A])
Eq[List[A]]
we'd define EqK[List]
, and the rest would be done by the conversion
EqK
as a separate typeclass, and duplicate the instances for Option, List etc. (I guess)
CofreeSuite
where it's defined explicitly :joy:
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
.
Ref
and Deferred
are coming from fs2, MVar
is coming from Monix (and of course from Haskell, although in Haskell you also have STM)
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
Ref.modify
Ref
is also lighter weight
Eq
variant sounds appealing, I could come up with a proposal
Deferred
is write-once
Ref
+ Deferred
you can implement structures that aren't
Semaphore
and Queue
in fs2 are implemented with Ref
+ Deferred
(used to be called Promise
)
MVar
allows you to do both at once
Ref
as something that could deal with concurrent state only
Deferred
is very simple: starts empty, becomes full, can't be emptied or modified again. get
on empty waits (asyncly), get on full immediately returns. complete
on empty unblocks the readers, complete
on full fails
MVar
gives a lot more ways to end up in deadlock