-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Override some methods in Kleisli instances #1618
Override some methods in Kleisli instances #1618
Conversation
- Switch the order of the traits so that some methods are overridden by the implementation in other type class instances in its hierarchy. - Add a `MonadReader` test for `Reader`
de594a0
to
5f61952
Compare
Codecov Report
@@ Coverage Diff @@
## master #1618 +/- ##
==========================================
- Coverage 93.11% 93.08% -0.03%
==========================================
Files 250 250
Lines 3992 3979 -13
Branches 138 141 +3
==========================================
- Hits 3717 3704 -13
Misses 275 275
Continue to review full report at Codecov.
|
Thanks @peterneyens! This generally looks really good to me. One minor question: was there any particular motivation for changing a bunch of implicit parameter names to something like |
Most of the parameters here in |
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.
LGTM 👍
Switch the order of the traits so that some methods are overridden by the implementation in other type class instances in its hierarchy
For example:
extends Monad[Kleisli[F, A, ?]] with KleisliApplicative[F, A]
extends KleisliApplicative[F, A] with Monad[Kleisli[F, A, ?]]
)We were already overriding
ap
inMonad
, this also overridesproduct
(which was the initial reason for this PR).For the rest we can just loose a couple of explicit overrides (eg
super[KleisliSplit].split(f, g)
)Add a
MonadReader
test forReader
, which improves some code coverage.