Implement a new typeclass hierarchy (again)

[endgame]

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]

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]

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.

[endgame]

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]

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

[tomjaguarpaw]

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]

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]

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.