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

Bifoldable Laws with non-commutative types #4361

Open
bpholt opened this issue Dec 29, 2022 · 0 comments
Open

Bifoldable Laws with non-commutative types #4361

bpholt opened this issue Dec 29, 2022 · 0 comments

Comments

@bpholt
Copy link
Member

bpholt commented Dec 29, 2022

I noticed that the existing bifoldable laws for Binested fail if you use Tuple2 instead of Either as the two-slot type constructor, and a non-commutative monoid for the innermost types. e.g. adding

checkAll(
  "Binested[Tuple2, ListWrapper, ListWrapper, *, *]",
  BitraverseTests[Binested[Tuple2, ListWrapper, ListWrapper, *, *]]
    .bitraverse[Option, Int, Int, String, String, String, String]
)

fails cats.tests.BinestedSuite.Binested[Tuple2, ListWrapper, ListWrapper, *, *]: bitraverse.bifoldRight consistent with bifoldMap, vs the existing one, which passes:

checkAll(
"Binested[Either, ListWrapper, ListWrapper, *, *]",
BitraverseTests[Binested[Either, ListWrapper, ListWrapper, *, *]]
.bitraverse[Option, Int, Int, Int, String, String, String]
)

Assuming the implementation is correct and the failure hasn't revealed a bug, it makes me wonder if there's a way to encode this in the types. Should the C: Monoid on BitraverseTests.bitraverse be C: CommutativeMonoid so that the law is more universal? If so, how far up the chain should that propagate? Ultimately it's used in BifoldableLaws.bifoldLeftConsistentWithBifoldMap and BifoldableLaws.bifoldRightConsistentWithBifoldMap.

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

No branches or pull requests

1 participant