Skip to content
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

Binary-compatibly move typelevel/algebra into cats repo #3918

Merged
merged 17 commits into from
Aug 25, 2021

Conversation

armanbilge
Copy link
Member

@armanbilge armanbilge commented Jun 4, 2021

Following directly from #3877 (comment).

Re-played commits from #3877:

  • 2c51138 Initial dump of algebra into cats
  • 71f397b Disable MiMa subsequently re-enabled
  • 080a539 @nowarn deprecations
  • 700c0b7 Migrate docs
  • c51b726 Reference cats-algebra in README/docs
  • 66b8074 Rename package algebra -> cats.algebra
  • a6ec3b8 Merge DeMorganLaws into LogicLaws per TODO
  • 8ddf2a4 Merge in algebra#246
  • 1ce0efd Remove unimplemented stubs
  • 39716dc Formatting
  • 5130867 Add kernel-laws dependency and refactor
  • 7ff1809 Delete priority deprecated instead
  • 048ce2e Implement algebra#108
  • b81e1fb Make Field inherit from DivisionRing
  • 844670d Rename laws -> tests, remove redundancies
  • 7ab3d90 Add Signed and TruncatedDivision typeclasses
  • b0c1ced More laws for Signed
  • 44eb36c Refactor instances to avoid conflicts/ambiguities

@armanbilge
Copy link
Member Author

Ok everyone, good news: I was able to rework @denisrosset's proposals typelevel/algebra#246 and typelevel/algebra#247 as well as typelevel/algebra#108 so that they are binary compatible 😅

Unfortunately I had issues with 44eb36c which tries to reduce potential for conflicts when using import algebra.instances.all._. It seems that marking as private[algebra] a trait method that is extended by a (package) object causes the static-forwarder for that method to disappear completely.

Still haven't brought in any of the significant changes to laws yet, but since it seems breaking bin-compat there could be okay they are less of a concern.

@armanbilge
Copy link
Member Author

armanbilge commented Jun 19, 2021

@denisrosset @larsrh @johnynek @mpilquist Ready for review. Hopefully we can wrap this up? :)

I decided not to make any binary-breaking changes to laws, doing so doesn't feel right under semantic versioning. Furthermore, I decided to keep everything in both core/laws source-compatible and added @deprecation warnings instead.

In the end I was able to replay most of the changes from the original PR. The glaring omissions are:

  1. Currently, both cats and algebra instances inherit from cats-kernel instances. So importing both could cause conflicts/problems, possibly? It doesn't seem possible to fix this in a binary-compatible way.
  2. The organization/naming scheme of algebra-laws is not very Cats-like (separation of laws and tests, etc.). Since breaking bincompat for laws seemed a possibility, I could still do this, but this would also mean breaking semantic versioning rules.

Thanks all!

@johnynek
Copy link
Contributor

I'll look soon. Note: removing "implicit" is actually binary (although not source) compatible.

Since source incompatibilities are always discovered by compilation but binary are often discovered via runtime crashes in transitive dependencies, I would consider removing implicits that conflict to be acceptable.

@armanbilge
Copy link
Member Author

armanbilge commented Jun 19, 2021

Note: removing "implicit" is actually binary (although not source) compatible.

Thanks, I am aware of this! See my comment above #3918 (comment) about the problems I had with this. I don't think removing implicit would help at the source-level without also marking as private[algebra], because implicits and non-implicits alike get imported with the usual wildcard imports. So conflicting names would still be a problem.

Copy link
Contributor

@johnynek johnynek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mostly good. I had a couple of minor comments.

* This type can be useful for problems where multiple algorithms can
* be used, depending on the type classes available.
*/
@deprecated("No replacement", since = "2.7.0")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this deprecated? It seems it is not deprecated in algebra?

The motivation is that some functions can be written that e.g. use either a Group or a Monoid. If you have a Group, it can be more efficient, or else you can fall back to Monoid (at a constant multiplicative cost).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: we could imagine pushing this onto Either[A, B] in the scala standard library (prefer Right, fallback to Left). Similarly with Option[A] and tuples, but I think the standard library currently does not allow this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just replaying 7ff1809 which was suggested on the original PR since it's not used in algebra itself. My bad, now I see its intrinsic value. I'll bring it back.

Btw I did see your plans to submit it to Scala standard library in typelevel/algebra#67!

fold[Option[F]](_ => None)(f => Some(f))
}

@deprecated("No replacement", since = "2.7.0")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we remove this?

@@ -0,0 +1,10 @@
package algebra.laws.platform

private[laws] object Platform {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@armanbilge armanbilge Jun 30, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have liked to, but that one is also private! Since they don't share the same package. Ok to make the cats-kernel one public?

|DistributiveLattice | ✓| ✓| | | ✓| | |
|BoundedLattice | ✓| ✓| ✓| ✓| | | |
|BoundedDistributiveLattice| ✓| ✓| ✓| ✓| ✓| | |
|Heyting | ✓| ✓| ✓| ✓| ✓| ✓| |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think Logic is missing from this table, btw...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you tell me which boxes to check I'll add it in real quick :) I'm ok with the first 5 columns or so, but a bit confused about the last two.

@armanbilge
Copy link
Member Author

@johnynek Thanks for the review, much appreciated. I've restored Priority to its rightful place.

@larsrh also expressed his overall approval, hopefully he can confirm here? :)

@larsrh
Copy link
Contributor

larsrh commented Jul 3, 2021

I remain unconvinced that this one is better than #3877, but will not stand in the way of getting this done.

@armanbilge
Copy link
Member Author

Just a polite bump :) does anyone else want to chime in? @denisrosset or @mpilquist?

valencik added a commit to typelevel/typelevel.github.com that referenced this pull request Jan 26, 2023
Algebra is a part of cats as of typelevel/cats#3918
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants