-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Monad[Future].>> behave strangely #1357
Comments
@weihsiu this is one of several places in which cats opts to take strict parameters while scalaz uses by-name parameters. Strict parameters have less overhead, so this decision was made for performance reasons (it can be a really big deal for things like If you want to reason about when your side effects will occur, you should probably use something like Task. I'll leave this open for now, as we probably should provide some documentation about strictness in cats vs scalaz and probably also specifically about |
thanks for the quick response! i also wondered about the strictness of Semigroup's combine. now that i know the answer, at least i know it's not an oversight. about Future though, i know it's not perfect, but many libraries return Future as it's async result. fs2.Task is not a cats Monad by default. i made fs2.Task a cats monad without checking the laws but that worked with ">>" when i convert scala Futures to fs2 Tasks. |
This is a tangent, but you might find the fs2-cats project helpful. |
thanks for the pointer! i was looking for just such a library before i wrote the task monad. |
I expected to find Shouldn't we either: a) move non-law abiding instances to alleycats or b) merge all of alleycats into cats. Doing both is very confusing and means there is no clear line in the. Or is this going to be addressed by https://github.com/typelevel/cats-effect ? // @djspiewak |
@fommil see some discussion around here: and also: https://gist.github.com/non/4d1f49fe41e2f12c463ae075bf5d0f06 the consensus was that we could not see anywhere these items violated laws without using non-functions (e.g. things that throw). This bug is actually that the caller assumed the side effects in So, we use What law is violated and why aren't the tests catching it? |
Yeah, I have to agree with @johnynek here. I don't know of any way of violating the monad laws using |
i have the following code snippet
Future { Thread.sleep(1000); println(1) } >> Future { println(2) }
in scalaz, it prints "1" and then "2"
but in cats 0.7.2, it prints "2" and then "1".
i don't know if this behavior is intentional or not, but imo, not intuitive.
this snippet though
Future { Thread.sleep(1000); println(1) } >>= (_ => Future { println(2) })
prints "1" and then "2" in both scalaz and cats.
The text was updated successfully, but these errors were encountered: