-
Notifications
You must be signed in to change notification settings - Fork 14
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
base: master
Are you sure you want to change the base?
Implement a new typeclass hierarchy (again) #64
Conversation
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 |
It represents "`SemiProductProfunctor` with a unit".
This places all three main ways of viewing this class on equal footing: * The "tupling profunctors" perspective: `p a b -> p a' b' -> p (a, a') (b, b')` * The "applicative output" perspective: `p x (a -> b) -> p x a -> p x b` * The "divisible input" perspective: `(a -> (b, c)) -> p b x -> p c x -> p a x`
0b04337
to
a8daae9
Compare
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. |
SemiproductProfunctor(..), | ||
(***$), |
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.
Should probably explicitly export ProductProfunctor(..)
and SumProfunctor(..)
in their respective sections?
-- | ||
-- /Since 0.12.0.0:/ Superclass constraint relaxed from @'Monoid' r@ | ||
-- to @'Semigroup' r@. |
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.
I don't know exactly how to word this but this probably isn't right.
Have you had a chance to look at this? If you're happy with the new typeclass design and the decision to start using |
Hello, sorry for the slow reply. This is on my TODO list but I'm only making progress on my list slowly ... |
By the way, adding these new combinators (but not deprecating the old versions) is easy to add in the current major release of
|
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). |
OK, so after investigation:
|
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 withvoidP
.empty
still exists but is deprecated.(***!)
moved toSemiproductProfunctor
(+++!)
moved toSemisumProfunctor
Open questions:
semigroupoids
; finessing our typeclasses so there's a "has unit/no unit" split is significantly less useful unless we can write instances in terms ofApply
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