Welcome! Got a question? Do you have -Ypartial-unification turned on? Other FAQs: http://typelevel.org/cats/faq.html
Another way to do it is to have
CanConstruct[F] { def make: F[Thing] } and use that everywhere, then have Sync[F] imply CanConstruct[F]. So you can get the instance at the top of your program but internal code will only know about CanConstruct.
@tpolecat thanks, interesting trick
Applicative[F].unit.map(_ => some initialization ) why this doesn't guarantee the same effect as delay?
It's the difference between
IO(println("hi")) and List(println("hi"))
Or (again if it's a pure value) you can use
Defer[F] to put off evaluation until it's needed, or you can use Eval, which is a concrete data type specifically for talking about evaluation semantics.
But if you're interacting with the side-effecting part of the language the only thing that's guaranteed to work is
Sync.
I wonder is there a beginner cheatsheet for cats typeclasses / effects? say, for common scenario X you'd better use Y?
There's a few images there that show the hierarchy of typeclasses, they're useful to reference when trying to find the best abstraction to use
Hi, a quick question: why is short circuiting behavior not implemented in
Apply[EitherT[F, xxx, *]].map2Eval ? We wanted to run an effect per list element -- and it kept on running after first failure when we wrote it the intuitive way by calling traverse. We then had to rewrite it using flatMap and manual recursion. Is this the desired/documented behavior?
I see there is no law that mandates short circuiting behavior of
map2Eval in the raiseError case in MonadError laws -- I think it makes sense to have it. https://github.com/typelevel/cats/blob/main/laws/src/main/scala/cats/laws/MonadErrorLaws.scala
everything goes
and my code can't compile. When I remove it, everything goes back to normal
Hi all,
I have the following use case
def getUsers(dateWindow: Interval[LocalDate]): IO[List[User]] = ???Ideally I'd like to iterate over the resulting Users using something like this
def getImportantUserReport(user: User): IO[Option[ImportantUserReport]] = ???But that won't compose. As in
for {
users<- getUsers(currentTimeWindow)
aUser <- users // <- NOPE
report <- getImportantUserReport(aUser)
// above pattern repeats multiple times
finalResult <- someFunction
} yield finalResultThe issue here is that I need User downstream to query other services, so my current solution does this
def getImportantUserReports(user: List[User]): IO[List[(User, Option[ImportantUserReport])]] = ???This works, but I can't help but feeling there's a more elegant solution that doesn't rely on passing data along with every function call.
Any hints will be much appreciated
getUsers(currentTimeWindow).flatMap { users =>
users.traverse(getImportantUserReport)
}
1 reply
Well, since you already have the
Option[Either[A, B]] it would be sequence
scala> import cats.syntax.all._
import cats.syntax.all._
scala> def test[A, B](x: Option[Either[A, B]]): Either[A, Option[B]] = x.sequence
def test[A, B](x: Option[Either[A,B]]): Either[A,Option[B]]
Li Haoyi once wrote a small library for stateful objects that were functional. I keep seeing references to this type of structure, but I can't remember the name right now.
I was thinking of using a functional stateful object in Akka, to reduce message passing. It's a long time (5 years or so) I looked at that lib, so I am not sure it's a good idea. I just wanted to check out if it fit.
But I can't find the library I had seen on his repo anymore.
yes, I can't quite remember what it did. The argument is that you could change the object that had state, and other ojbects would get the state change on using it. But somehow it was not OO...
I think there was an example using equations and variables
God it: Rx Reactive variables. His library is here.
I guess what I was thinking of falls probably in the space of premature optimisation. The thought was of sharing state with child actors, since On the same VM one does not really need message passing....
