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

Implement a new typeclass hierarchy (again) #64

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

endgame
Copy link
Contributor

@endgame endgame commented Apr 10, 2023

Rebuilding my take on the hierarchy hashed out at the end of the comment thread on #54 in a commit-by-commit branch

Defines:

  • Profunctor => SemiproductProfunctor => ProductProfunctor

    This operates on tuples, and gives the operations from the
    Applicative(Apply) and Divisible(Divise) typeclasses.

  • Profunctor => SemisumProfunctor => SumProfunctor

    This operates on Eithers, and gives the operations from the
    Decidable (Decide/Conclude) typeclasses.

Breaking changes:

  • purePP -> pureP for consistency with everything else.
    • purePP still exists but is deprecated.
  • empty -> unitP for consistency with voidP.
    • empty still exists but is deprecated.
  • (***!) moved to SemiproductProfunctor
  • (+++!) moved to SemisumProfunctor
  • New superclasses introduced - downstream will need to write more instances.

Open questions:

  • Are you happy with these {class,operator,function} names?
  • I think we should depend on semigroupoids; finessing our typeclasses so there's a "has unit/no unit" split is significantly less useful unless we can write instances in terms of Apply etc. If you agree, I will add a semigroupoids commit to this PR.

Tests are currently busted because makeAdaptorAndInstance is completely busted, but I wanted to get eyes on this before I forget to look at it for another year.

Needs to be rebased after #61, #62, and #63 all go out.
Closes #54
Closes #59
Closes #50

@tomjaguarpaw
Copy link
Owner

This will take me a while to look at (and needs rebasing now), but I release the non-breaking changes to Hackage in the meantime: https://hackage.haskell.org/package/product-profunctors-0.11.1.0

@endgame endgame force-pushed the semi-sum-and-product-profunctors-take-2 branch from 0b04337 to a8daae9 Compare April 17, 2023 12:19
@endgame
Copy link
Contributor Author

endgame commented Apr 17, 2023

Rebased and pushed. TH is still broken, which breaks CI; I don't really want to wrangle TH until we agree on the interface again.

Comment on lines +42 to 43
SemiproductProfunctor(..),
(***$),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should probably explicitly export ProductProfunctor(..) and SumProfunctor(..) in their respective sections?

Comment on lines +124 to +126
--
-- /Since 0.12.0.0:/ Superclass constraint relaxed from @'Monoid' r@
-- to @'Semigroup' r@.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know exactly how to word this but this probably isn't right.

@endgame
Copy link
Contributor Author

endgame commented May 10, 2023

Have you had a chance to look at this? If you're happy with the new typeclass design and the decision to start using semigroupoids classes, then I'll work on fixing up the instances and the TH.

@tomjaguarpaw
Copy link
Owner

Hello, sorry for the slow reply. This is on my TODO list but I'm only making progress on my list slowly ...

@tomjaguarpaw
Copy link
Owner

By the way, adding these new combinators (but not deprecating the old versions) is easy to add in the current major release of product-profunctors, so if you want to make a PR that just adds them I'm happy to incorporate and release.

  • purePP -> pureP for consistency with everything else.
  • empty -> unitP for consistency with voidP

@tomjaguarpaw
Copy link
Owner

Having said that, I do need to think about how to do this in a way that makes the upgrade path as smooth as possible (unless you or I already did that, and I forgot about it).

@tomjaguarpaw
Copy link
Owner

tomjaguarpaw commented May 16, 2023

OK, so after investigation:

  • We can just go head and add pureP. Why not? It's just going to end up there anyway. [EDIT: corrected unitP to pureP]
  • We can't add unitP because what's currently called SumProfunctor should be called SemisumProfunctor, and unitP is going to end up in the new, correcter named SumProfunctor.

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.

Put minimal pragma on ProductProfunctor
2 participants