-
-
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
Bump ScalaCheck to 1.13.1, and fix the fallout. #1345
Conversation
I should also note that I commented out some other implicits that we can probably remove. I definitely need to do a sweep through this PR before we consider merging it, but I wanted to get it up now to show people how things work. We also probably want to add |
Hit another cryptic issue, with the
I was able to work around this, but it's really unnerving. I pushed the workaround to get the PR to turn green, but ideally we should fix this before merging. I'm going to create a checklist in the PR to try to track these deferred issues. |
I was wrong -- all of the tests seem to be broken under scala.js. I'm going to put this down and come back to it. I should probably download some ScalaCheck jars to be sure that they look OK. |
I still haven't figured out what is happening here. I tried on a different computer and was able to test some of these sub-projects but encountered the error in another place (free). I've tried cleaning (and manually nuking I also asked in the Scala.js Gitter and no one had any ideas. I'm a bit stumped. If anyone is looking for a frustrating thing to work on this weekend I'd appreciate some help. Even just checking out this branch and running (I'm going to be out of town for a couple days, so I may not be as responsive as I have been recently.) |
I've sent a pull request, please take a look (direct link to the commit: non@191e51f). With this commit, I'm not exactly sure what's actually happening, but an educated guess is the following:
I hope this helps :-) |
@durban Thanks so much!!! I merged this to get Travis started but I'm also going to run it locally. The explanation seems plausible, and might explain why the problems are somewhat unpredictable. |
Current coverage is 91.73% (diff: 76.92%)@@ master #1345 diff @@
==========================================
Files 238 238
Lines 3579 3594 +15
Methods 3508 3528 +20
Messages 0 0
Branches 70 65 -5
==========================================
+ Hits 3284 3297 +13
- Misses 295 297 +2
Partials 0 0
|
For now I've elected to remove the left distributivity law from If anyone feels strongly I'm also fine with downgrading |
(Sorry for all this test noise. I will probably rebase the last few commits here, since they basically just consist of me using Travis to do testing.) |
This commit gets all our law tests working with a new, more robust ScalaCheck version. It currently relies upon an unreleased Discipline snapshot, so it definitely won't build in Travis. There were a bunch of test bugs that got fixed, mostly around foldRight/reduceRight consistency for non-empty data structures. One law violation was uncovered: MonadCombine[Option] doesn't pass the left-distributivity law we wrote. We should figure out whether this represents a real law violation and remove the instance, or whether the law is too strict somehow. One counter-example is: def f(x: Int): Option[Int] = if (x == 0) None else Some(x) val a = Option(0) val b = Option(1) (a <+> b).flatMap(f) != (a.flatMap(f) <+> b.flatMap(f)) Review by @adelbertc et al. We will need to wait for a new Discipline release before merging this, and we'll need to do something about the MonadCombine laws/instances (currently the MonadCombine[Option] test is commented out).
Also remove various obsolete/commented code.
62fccae
to
742e1d2
Compare
If I recall @mpilquist had knowledge around weak/strong laws, might the left-distributivity law of |
I don't think we should worry about the coverage errors here. AFAIK the uncovered parts of the patch are cogen instances I created for some of our data types. I thought they were needed (but maybe weren't used) but I think we should include these anyway. |
+1 on removing monadCombineLeftDistributivity. A useful law to add might be enforcing |
@eed3si9n Agreed on that! I think we get this for free since we're also checking both the |
@non They both introduce |
@eed3si9n One of us must be confused. I'll try to lay out my reasoning to figure out where the confusion lies:
Am I missing something? It seems like we're already ensuring consistency through the law-checking, right? |
@non For clarification, let's call the Here's my logic:
It's completely possible that I'm confused. |
@eed3si9n If the method was called |
So you're saying that the implementation of emptiness would never diverge because no one would define instances like this in real life? implicit def instancesForEither[A1: Monoid]: MonadCombine[Either[A1, ?]] with Monad[Either[A1, ?]] with Alternative[Either[A1, ?]] {
def empty[A2]: Either[A1, A2] = Left(???)
....
}
implicit def instancesForEither2[A1]: MonadFilter[Either[A1, ?]] {
def empty[A2]: Either[A1, A2] = Right(???)
....
} |
@eed3si9n Right. Or at least, defined that way there would be ambiguous implicit problems. Now I understand the issue you're pointing out. I think it's a valid concern but it's a lot deeper than just this case: for example, what if there were both If you want I can open an issue to think about how best to ensure this doesn't happen (even if we write out own test, there's no guarantee that someone else down the line doesn't set up a bizarre set of implicits somewhere). |
Cogen[Long].contramap(_.toLong) | ||
|
||
implicit val cogenBigDecimal: Cogen[BigDecimal] = | ||
Cogen[Double].contramap(_.toDouble) |
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.
It looks like scalacheck has Cogen
instances for BigInt
and BigDecimal
. Is there a reason we need separate instances here? If so, we probably should document it.
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.
Those are only in master and were added (by me) recently in a just-merged PR. I think we still need them until another release is out.
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 okay.
👍 LGTM but I think that we should create issues to follow up on the left-distributivity law and the short-lived cogen instances. |
By the way, @non I'm really excited about this, and it's fantastic that it caught an issue! |
We provide some Cogen instances which were not included with 1.13.2. These instances will be provided in a future release, so when they become available we should remove ours. This commit also removes one instance that wasn't in 1.13.1 but was available in 1.13.2: Cogen[Stream[A]].
@ceedubs It turns out one of the instances (
|
I'm not super excited about losing a law. I'd rather lose an instance unless we can make a strong case as to why the law is overly tight. |
@johnynek One reason not to mandate it is that there seems to be disagreement about what laws this structure should obey: https://wiki.haskell.org/MonadPlus It seems like the options are:
Either of these would be valid laws to have. One suggestion would be to have two type classes, each with one of these laws. Supporting the left catch style might be nice for types like That said, I'm fine with removing it if everyone else agrees that we want to commit to the left distribution flavor of |
Hi Guys, I'm keen to get this PR in if possible so I can (hopefully) put in a PR for 2.12.0-RC1 but it needs the new versions of libs this PR brings in. If there are some open questions, is it possible that they could be moved to a new issue/PR so I can PR on top of this one? |
Or, I see that this is on the 0.8.0 milestone, so perhaps merge to a 0.8.x branch? (along with #1333 ;) ) |
@non what about following Haskell's proposal: |
I'm 👍 on this since the scope of this already rather large PR was to get us up to date on dependencies. That Haskell proposal is interesting though - if folks are OK let's call this good and we can create a ticket to follow up with figuring out what we want to do with MonadPlus? |
👍 on the merge for this along with a ticket that we address the idea of
|
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.
👍 per @adelbertc and @johnynek's above comments.
I've created #1381 to follow up on the left-distributivity law.
Status
MonadCombine
lawsSummary
This commit gets all our law tests working with a new, more robust
ScalaCheck version. It currently relies upon an unreleased Discipline
snapshot, so it definitely won't build in Travis.
There were a bunch of test bugs that got fixed, mostly around
foldRight/reduceRight consistency for non-empty data structures.
One law violation was uncovered: MonadCombine[Option] doesn't pass the
left-distributivity law we wrote. We should figure out whether this
represents a real law violation and remove the instance, or whether
the law is too strict somehow.
One counter-example is:
Review by @adelbertc et al. We will need to wait for a new Discipline
release before merging this, and we'll need to do something about the
MonadCombine laws/instances (currently the MonadCombine[Option] test
is commented out).