-
-
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
Change forEffect/followedBy to productL/productR #2083
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Just realized I missed a bunch of other methods. working on that. |
Thanks! @Jacoby6000, a scalafix migration would be handy. Let me know if you are interested in giving it a try or I can add it in a follow-up PR. Here is a good example for such rename migrations. |
also, we won't have RC2, so all the deprecation note should be |
@kailuowang I built the scalafix stuff, but it seems to cause some problems. forEffect and followedBy were introduced during 1.0.0, and I'm not sure how to split up the fix migrations. I've pushed my scalafix work in to #2083-scalafix. |
The problem is that the Scalafix test depends on 0.9 right? I would say for this PR we simply don't test this migration. It should be low risk |
👍 once there is resolution on the scalafix rules. I don't think that any word-based name is going to be perfect, but |
I've added in the scalafix stuff that I drafted. I can't test it, so please look it over 😅 |
for the scalafix stuff, if you include the input and output they will be compiled, which fails due to mis-dependency as we discussed earlier. Sorry I wasn't clear, by "don't test" I mean we shouldn't include them in the input and output of the scalafix tests. Also bin compact check failed, need to add mima exceptions ( you can check CI log to see which ones are needed, or you can leave that to us). |
Think faq page needs to be updated as well? |
close and reopen to trigger build |
I’m -1 on apL and apR the more I think about it. Note we already have ap. And these new methods are not that similar. I would say productR and productL are much better. |
I am fine with |
I'm not much of a fan of As for the methods not being related, I think their relationship becomes more clear if you define As an aside, def apL[F[_]: Apply, A, B](fa: F[A])(fb: F[B]): F[A] =
map2(fa, fb)((a, _) => a)
def apR[F[_]: Apply, A, B](fa: F[A])(fb: F[B]): F[B] =
map2(fa, fb)((_, b) => b)
def map2[F[_], A, B, C](fa: F[A], fb: F[B])(f: (A, B) => C)(implicit F: Apply[F]): F[C] =
F.ap(F.map(fa)(a => (b: B) => f(a, b)))(fb) |
I'm willing to submit and change it to productL and productR to appease the community; I only ever use the proper notation anyway. |
Going deeper in to the relationship, and why I think
I think having names which are as analagous as the symbols does a great deal towards teaching the notation. If people never use |
I agree with some of what you say, I feel like you are overlooking that I hear you that you don't like If you don't like them, I'm pretty happy to keep the current names since I think as long as names don't mislead (and I feel apR and apL do), I don't think they matter too much, so forEffect is just a pointer to the docs which often has a good mnemonic. To me, that's fine. |
I'm going to update this PR to use |
@Jacoby6000 thanks very much! Hate to ask you one more thing, we ended up deciding that we are going to have a quick |
I'll have time in a few hours, if it can wait. |
core/src/main/scala/cats/Apply.scala
Outdated
@@ -62,7 +63,7 @@ trait Apply[F[_]] extends Functor[F] with Semigroupal[F] with ApplyArityFunction | |||
* map2 can be seen as a binary version of [[cats.Functor]]#map. | |||
*/ | |||
def map2[A, B, Z](fa: F[A], fb: F[B])(f: (A, B) => Z): F[Z] = | |||
map(product(fa, fb)) { case (a, b) => f(a, b) } | |||
ap(map(fa)(a => (b: B) => f(a, b)))(fb) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a sensible improvement if we only consider the default implementation, but many instances overrides product
for better performance. So we might want to keep the original implementation of product
and map2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually the law is broken with Const
instance which overrides product
ConstSuite:
[info]
[info] - Apply[Const[NonEmptyList[String], Int]].apply.map2/product-map consistency *** FAILED ***
[info] GeneratorDrivenPropertyCheckFailedException was thrown during property evaluation.
[info] (Discipline.scala:14)
[info] Falsified after 3 successful property evaluations.
[info] Location: (Discipline.scala:14)
[info] Occurred when passed generated values (
[info] arg0 = Const(NonEmptyList(ꙫ, 鰓)),
[info] arg1 = Const(NonEmptyList(, )),
[info] arg2 =
[info] )
[info] Label of failing property:
[info] Expected: Const(NonEmptyList(, , ꙫ, 鰓))
[info] Received: Const(NonEmptyList(ꙫ, 鰓, , ))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah Yeah, that was a bit short sighted of me. I didn't consider overrides.
Thanks very much! @Jacoby6000 |
Yes, thanks a lot, Jacob! :) |
"_root_.cats.NonEmptyParallel.parFollowedBy." -> "parApR", | ||
"_root_.cats.FlatMap.forEffectEval." -> "apLEval", | ||
"_root_.cats.FlatMap.followedByEval." -> "apREval", | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These rewrite rules still need to be updated to productR
/productL
, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yep, they sure do. I missed those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix submitted #2117
This should resolve #1983.
I picked apL and apR based on discussion in that issue.
The deprecation caused scalac to complain about the code generated by simulacrum, so I moved the deprecated method aliases in to syntax.apply.