-
-
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
Syntax for function1 kleisli-composition #3396
Syntax for function1 kleisli-composition #3396
Conversation
We could skip the wrapping in |
In terms of test, I think some simple doctests would be enough I think (along with the syntax tests you already wrote) :) |
Codecov Report
@@ Coverage Diff @@
## master #3396 +/- ##
==========================================
+ Coverage 92.49% 92.67% +0.17%
==========================================
Files 378 379 +1
Lines 7956 7984 +28
Branches 227 230 +3
==========================================
+ Hits 7359 7399 +40
+ Misses 597 585 -12
Continue to review full report at Codecov.
|
Addressed that and changed it to use |
* res2: Option[Int] = None | ||
* }}} | ||
*/ | ||
def >=>[C](g: B => F[C]): A => F[C] = a => FlatMap[F].flatMap(f(a))(g) |
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 we @inline
this?
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.
my two cents here, the other syntax ops are not inlined in general so I wouldn't do it.
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.
thanks!
I think this would benefit from also having non-symbolic names - maybe |
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.
In Cats we've been leaning towards having non-symbolic names (with symbolic alias) in most if not all cases. Can we stick to that convention here too?
Sure! Any preference for the method name? |
I like |
Codecov Report
@@ Coverage Diff @@
## master #3396 +/- ##
==========================================
- Coverage 92.49% 91.60% -0.89%
==========================================
Files 378 382 +4
Lines 7956 8307 +351
Branches 227 218 -9
==========================================
+ Hits 7359 7610 +251
- Misses 597 697 +100 |
This PR aims to add syntax for easily composing functions without wrapping them into
Kleisli
manually, based on a gitter conversation: https://gitter.im/typelevel/cats?at=5e971c478821056d3e124e4a (@Daenyth @LukaJCB)I looked into the tests, but I'm unsure what tests to write for the syntax methods that are added in this PR. Optimally I would like to write a property test / law in the style offorAll{ f >=> g <-> Kleisli(f) >>> Kleisli(g) }
TODO